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NOTICES 

The software described In this manual is licensed, not sold. Use of the soft- 
ware constitutes agreement by the user with the terms and conditions of the 
End-User License Agreement packaged with the software. Read the Agreement 
carefully. Use in violation of the Agreement or without paying the license 
fee is unlawful . 

Every effort has been made to make this manual as accurate as possible. How- 
ever, MetaWare Incorporated shall have no liability or responsibility to any 
person or entity with respect to any liability, loss, or damage caused or 
alleged to be caused directly or Indirectly by this manual, including but not 
limited to any interruption of service, loss of business or anticipated 
profits, and all direct, indirect, and consequential damages resulting from 
the use of this manual and the software that it describes. 

MetaWare Incorporated reserves the right to change the specifications and 
characteristics of the software described in this manual, from time to time, 
without notice to users. Users of this manual should read the file named 
"README" contained on the distribution media for current information as to 
changes in files and characteristics, and bugs discovered in the software. 
Like all computer software this program is susceptible to unknown and un- 
discovered bugs. These will be corrected as soon as reasonably possible but 
cannot be anticipated or eliminated entirely. Use of the software is subject 
to the warranty provisions contained in the License Agreement. 
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Feedback, Please 

(Upon first reading.) 

We would greatly appreciate your ideas regarding im- 
provement of the language, its compiler, and its documen- 
tation. Please take time to mark up the manual on your first 
reading and make corresponding notes on this page (front and 
back) and on additional sheets as necessary. Then mail the 
results to: 

MetaWare^ Incorporated 

412 Liberty Street 

Santa Cruz, CA 95060 

MetaWare may use or distribute any information you supply 
in any way it believes appropriate without incurring any obli- 
gation whatever. You may, of course, continue to use that 
information. If you wish a reply, please proyide your name and 
address. Thank you in advance. The Authors. 
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Temporarily, this mannal has 
been printed via dot matrix 
rather than typeset. 

The manual is expected to be 
typeset soon, after some feed" 
back comes in from early custo" 
mers. 

Since such things often get 
delayed, please be sure to send in 
your feedback as soon as possible 
~ if your suggestions do not get 
in the first typeset version, they 
may have an effect on the next. 

Thank you for your patience, 
understanding, and suggestions. 

The folks at MetaWare. 
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1 
Introduction 

1 . 1 Scope, Audience, Purpose 

This is a language reference nnanual for C. It does not 
attempt to teach C programming to those unfamiliar with the 
language. For an informal Introduction to C, consult Kernl- 
ghan and Ritchie [K&R]. 

The writing of this manual was prompted by the lack of any 
precise description of C. A common way to answer a question 
about C is to "see what the compiler does". This is anathema 
to writing programs, portable or not. Clearly C has suffered 
from beinq partly defined, then Implemented. The original 
definition [K&R] is quite incomplete. 

Our goal here is to provide a single document that answers 
all machine- independent questions about C. To that end we use 
formal notation, such as context-free grammars, where 
possible to avoid ambiguities. Thus, the reader of this manual 
must have a tolerance for formality, but hopefully will be 
rewarded by always getting answers. 



1.2 Need for Formality 

To illustrate a question poorly addressed in the literature, 
consider this C program fragment: 



struct s *p; 






/* Declaration A. 


*/ 


int f { 










struct s {int 


x,yj 


:}; 


/♦♦ Declaration B. 


*/ 


p->x « 1; 






/*• Reference R. 


»/ 


} 










int g() { 










p->x = 1; 

} 






/* Reference S. 


»/ 
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Is this a legal C program? The issue at hand is whether 
declaration B "oonnpletes'' declaration A by supplying the 
fields X and y. The original definition of C [K&R] does not say 
how A and B relate, if at all. Another recent book on C [H&S( 
says that "a structure type reference [may] precede the cor- 
responding type definition (provided the reference occurs in a 
context where the size of the structure is not required)". Is 
definition A above a type reference preceding the correspond- 
ing type definitions? 

For at least one compiler [4.2BSD] the answer is yes, so 
that within function f reference R Is permitted. However, 
after the closing brace of f, the completion B is somehow lost 
so that reference S Is illegal. Yet declaration A can no longer 
be completed: supplying another completion draws an error 
diagnostic. 

No published C reference known to us properly addresses 
this issue. The answer we provide is that a structure declara- 
tion can complete a previous one only if both are "declared at 
the same level", a notion that we make precise. 

1.3 Which C? 

When we claim to give a language definition for C, a 
question arises: "Which C?". The original definition of C 
[K&R] did not give C a complete definition. Compilers for C 
differ where K&R is silent or obscure. 

In some sense we are defining what C "should be" or 
"should have been defined as". In doing so we are not defining 
an entirely new language, including in it all of our favorite 
constructs. Instead, we observed what existing C compilers 
for C do with C's ill-defined spots, and produced a definition 
that attempts to be faithful to the most rational decisions 
made in those compilers. 

Furthermore we took into consideration the C language 
draft standard produced by the ANSI C standardization com- 
mittee X3J11 (and have participated in the development of 
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that document). The X3J11 standard is another C definition^ 
although less formal than ours, that tries to clarify the 
obscure and define the ill-defined, in addition to extending C 
where the K&R language is perceived as being weak. 

Therefore this document should on the whole be compatible 
with most C compilers, especially with those written with 
attention paid to X3J1 1"s work. We also point out where our 
definition differs from that typically implemented by popular 
compilers, or where it differs from the X3J1 1 work. 

A few of the language features we describe exist in no other 
C compiler or definition or in the X3J1 1 work. These features 
are particular to Meta Ware's own High C language. Most are 
simple changes, and are included in the main body of the 
language definition; those that are not simple are relegated to 
Appendix Language Extensions. All extensions, however, in- 
cluding those originating in X3J11, are listed in that appendix 
and the reader is invited to consult it for a summary. 

1.4 Exclusions 

For the purposes of this manual, the C library is not 
considered part of the C language and is not treated here. The 
ANSI standardization of C includes a library standard along 
with a language standard, but also recognizes so-called 
"freestanding environments" that do not Include any library. 
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1.5 Format 

[Syntax, Constraints, Senantics, Discussion, nachine Dependencies] 

In this manual each C construct Is presented in several 
sections: 

Syntax gives a regular-right-part context-free grammar 
that describes the syntactic structure or "form" 
of the construct. Section Ab/^/zb/? explains gram- 
mars and how syntax is divided into two levels: 
lexicon and phrase structure. 

Constraint$\\%\% rules that each instance of the construct 
must obey statically if it is to be well-formed. 
Such rules are in addition to the requirements im- 
posed by the grammar, and generally are rules that 
cannot be described by a context-free grammar. 

Semantics states the meaning of a well -formed construct; 
e.g. what happens at run- time: what value or 
effect it has. 

Discussion describes differences, extensions, and restrictions 
of this definition as compared to other C language 
definitions [K&R] [X3J11], or as compared to a 
popular implementation [4.2BSD]. Ramifications 
of the language definition that might otherwise go 
unnoticed are noted here. Occasionally we include 
examples and/or a brief summary description of 
the construct, especially when such is useful to 
illuminate why the construct was put in the lan- 
guage the way it was. 

t^achine Dependencies 

describes aspects of the construct that are parti- 
cular to certain machines. 

Any of these sections may be omitted, as appropriate. Foi^ 
example, if section "l^aciiine Dependencies** \% omitted, ont 
may infer that there are no known or relevant machine depen- 
dencies for the particular construct. Occasionally, sections 
that would otherwise be omitted are included for emphasis. 
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Material that should be Included In D/sci/ss/'onnyay instead 
be Included In the other categories, when nnoving it to 
D/scuss/on vioM place the material too far out of context. 
Such material Is flagged by the brackets Note and End of 
Note, We emphasize that such material is commentary only 
and not necessary to the language definition. 

Examples are generally started by the text Examph. 
When It may be unclear where the end of the example Is, the 
text End of Exampie\% used. 

Some authors prefer to use the phrases "Context-free 
Syntax" and "Context-Sensitive Syntax" Instead of "Syntax" 
and "Constraints". Still others prefer "Static Semantics" to 
"Constraints" and "Dynamic Semantics" to "Semantics". 
Rather than take sides we have used different terms. 



1 .6 Key Words and Phrases 

[sanple; uord or phrase] 

Following most subsection headers Is a line such as the 
latter containing key words and phrases related to that 
subsection. They give a quick Idea of what the section is about. 
The Index lists each word or phrase alphabetically by word or 
each word in a phrase. 
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1.7 References 

[K&R] Kernighan, Brian W. and Dennis M. Ritchie: The C 
Programming Language. Prentice- Hal 1^ Inc. 
Englewood Cliffs, NJ 07632,1978. 

[H&S] Harbison, Samuel P. and Guy L. Steele, Jr.: C: A 
Reference Manual. Prentice-Hall, Inc., Englewood 
Cliffs, NJ 07632,1984. 

[X3J11] American National Standards Institute X3J11 com- 
mittee on the standardization of the C program- 
ming language. X3 Secretariat, CBEMA, 311 First 
Street NW, Suite 500, Washington, DC 20001. The 
draft document from which we cite differences is 
dated April 30, 1985, document 85-045, and is 
aval I able from CBEMA at the above address. 

[4.2BSD] The portable C compiler as it exists on Berkeley's 
4.2 distribution of the UNIX operating system on 
Digital Equipment Corporation's VAX computers. 

In the sequel, the following abbreviations hold: KR for [K&R], 
X3J1 1 for [X3J1 1] , and 4.2BSD for [4.2BSD]. 
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2 
Notation 

2.1 Lexicon versus Phrase-Structure 

[lexical versus phrase-structure syntax; wrds, texts; constraints; 
context-free grannar; regular expressions] 

Syntax-can be usefully broken into two parts: lexicon and 
phrase-structure. 

Lex/c3/ syntaxreiers to the valid sequencing of characters 
in a progrann to form words, and the nanning of those words. 

Phrase'structure syntax rei^TS to the valid sequencing of 
the words to form phrases. 

For example, consider the C program 

mainO {int i ■ 1;} 

On the lexical level, the program appears as the character 
sequence 

m, a, 1, n, \ , ) , , \ , i, n, t, 

tl l^t II II II 141 I.I *\* 

The lexical syntax, as will be seen, permits such a character 
sequence and specifies the corresponding word names and their 
associated sequences of characters, or textsi indicated next; 

Word name Text 

<IDENTIFIER> 'm*, 'a', 'i', 'n' 

( (none) 

) (none) 

{ (none) 

int (none) 

<IDENTIFIER> 'i' 

= (none) 

<INTEGER> • 1 • 

(none) 
} (none) 
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At the phrase-structure leveL the sequence of words above, 
namely, 

<IDENTIFIER> ( ) { int <IDENTIFIER> « <INTE6ER> ; } 

is a valid C program. Hence the original character sequence 
forms a valid C program, at least on the lexical and phrase- 
structure levels. Note that some of the words illustrated 
above have no text. This Is by design and not by any restric- 
tions inherent in the formalisms used here. 

Phrase-structure description Is concerned only with the 
names of words, never with texts (with one exception in 
Section Preprocessoi). For example, C's phrase structure 
specifies that an <IDENTIFIER> be the name of a function, not, 
say, an <INTE6ER>; but which <IDENTIFIER> in particular is not 
a phrase- structure concern. 

On the other hand, the constraints of C — the context- 
sensitive syntax — are concerned with the texts of <IDENTI- 
FIER>s. For example, a usage of an <IDENTIFIER> with text J 
must generally follow a declaration of an <IDENTIFIER> with 
text T. 

C's lexicon and phrase structure are each formally defined 
here by a context-free grammar. 

Grammar illustrations. Illustrations from each kind of 
grammar are appropriate before proceeding further. 

Consider a fragment from the lexical grammar: 

Identifier-> Letter (Letter I Digit)* =>'<IDENTIFIER>'; 
Letter -> 'A'.. '2' | •a'..'2' | '_' ; 
Digit -> •0'..'9' ; 

The ''=>'<IDENTIFIER>"' specifies that a word is to be named 
<IDENTIFIER>. The text for that word is a letter followed by 
zero or more letters and digits, where a "letter" includes thp 
underscore ('_') character. 
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According to the lexical grammar, words can generally 
appear in any order, as indicated by the following lexical 
grammar fragment near the top of the grammar: 

Words -> Word*; 

Word -> String | Char j Number | Identifier 

I Delimiter | Punctuator | Operator | Comment; 

As an illustration from the phrase-structure grammar, 
consider the rule 

Statement 

-> 'for' '(• First: EL? 

';• Next: EL? 

•;• Last: EL? 

• ) ' Body: Statement 

It describes the C for statement, consisting of: 

the words for and ( , 

(optionally) any sequence of words generated by the 
nonterminal EL, the word ; , 

(optionally) any sequence of words generated by the 
nonterminal EL, the word ; , 

(optionally) any sequence of words generated by the 
nonterminal EL, the word ) , 

and finally any sequence of words generated by the 
nonterminal Statement. 
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2.2 Grammar Notation 

[context-free grannar; regular expressions: list, "•", "♦", "?", 
*|", ".."; a<JjecUvcs; <OELETE>, <ASJS>; reserved «ord] 

The context-free grammars used here contain regu/a* 
expressions;, which are expressions composed with postfix 
K +/ ?) and infix (list, j, . .) operators having the following 
meanings: 

Express/on means 

X* zero or more Xs. 

x+ one or more xs. 

X? zero or one X, i.e. X is optional. 

X|Y either X or Y. 

X list Y one or more Xs, separated by single occur- 
rences of Y; equivalent to X (Y X)* and 
(X Y)* X, giving X, X Y X, X Y X Y X, etc. 

X. . Y the sequence of characters from X to Y, in- 

clusive (meaningful only in lexical grammars). 

*, L ?, and . . were used in the grammar examples above. 

All terminal symbols, e.g. 'for' and •_', are single-quoted 
in grammars to avoid ambiguity. Nonterminals are not quoted, 
e.g. Statement and Letter. 

Parentheses of the forms (...) and <...> in grammars override 
precedence. In a lexical grammar the operator => specifies 
the name of a word; the name is the string following the =>. 

So-called adjectives \x\ grammars describe phrases of the 
grammar. The practice is borrowed from the Ada reference 
manual, where adjectives are typeset In italics. For example, 
Static_^Y.^T^%%\^x\ in Ada Is really the nonterminal Expression, 
but with the "reminder" that the Expression must be 
"static". 

Adjectives are purely commentary in grammars, but often 
an adjective Is mirrored in a constraint. Here we employ nor- 
mally- typeset (non- italicized) identifiers followed by a ":" to 
denote adjectives. Adjectives appeared in the phrase-structure 
examp I e above; viz. First, Next, Last, and Body. 
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Grammars may contain comments, which begin with "#" 
and continue to the end of the line. 

Special words. The words <DELETE>, <AS_IS>, and <IDENTI- 
FIER> have special meanings in lexical grammars, as follows: 

A word named <DELETE> is not to be considered in phrase- 
structure or any other analysis. <DELETE> is used so that 
comments and so-called "whitespace" need not clutter the 
phrase-structure grammar. Effectively, lexical analysis 
deletes such words. 

A word named <AS_IS> with text T Is to be instead consi- 
dered the word named T, with no text. For example, the word 
<AS_IS> with text ( is instead the word (. This device is 
employed in naming operator and punctuation symbols. 

Finally, any word named <IDENTIFIER> with text T is to be 
Instead considered a word named T If T appears in the phrase- 
structure grammar. For example, the <IDENTIFIER> word with 
text 'f 'o* 'r' is to be considered instead the word 'for', 
which appears In the phrase-structure grammar. These 
reserved <IDENTIFIER>s, called reserved words, are thus 
distinguished from ordinary < IDENTIFIER >s. 

Additional notation. We defer explaining some rarely- 
used grammar constructs to the sections where they are used. 



2.3 Lexical Ambiguity 

The lexical grammar is ambiguous, for economy of expres- 
sion. For example, the characters 'A', 'B', '1' can be inter- 
preted as the word <IDENTIFIER> with text 'A*, 'B', 'V or the 
two <IDENTIFIER>s 'A' and 'B' and the <INTEQER> '1'. In all 
cases ambiguity is resolved in favor of the longest possible 
word. 
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2.4 Program Text Conventions 

C program fragments in running text are double- quoted, 
and reserved words are boldfaced. For example: "int >cy;" 
In addition, C text is always reproduced in fixed-width font 
rather than varying-width font. Examples apart from running 
text are not quoted. 

2.5 Constraints and Semantics 

The specification of constraints and semantics is keyed to 
the nonterminals and adjectives in the grammar. Consider the 
phrase-structure grammar fragment: 

External_declaration 

-> Unspecif ied_declaration: 

( Funotion^definition 

I Non_function_definitions 

) 
-> Specif ied_declaration # With specifiers. 

-> •; ' # Allowed by KR. 

Specifications may be keyed to any of the nonterminals Speci- 
<ied_deolaration, Function_def initios Non__function_defi- 
nitions, or the adjective Unspecified_declaration, which 
"modifies" the alternation (|). As mentioned before. Adjec- 
tives do r?ot Uqure in the formal grammatical definition of 
the context-free syntax. 

2.6 Section References 

References throughout the text from one section to other 
sections are made by section and subsection title only, except 
when subsection references are made within a section, where 
the subsection number is most often used. A '/' separates a 
section title from a subsection title, when the latter ir 
included. For example. Section Concepts/Li fetime$Tt\^r% to 
Section ^^/7^^/7/t?, Subsection Lifetimes. The location of each 
section and subsection can be found In the Table of Contents. 
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2.7 Composition of a C Program 

[source files; conpilation unit; linking; progran execution; 
independent translation; preprocessor] 

A complete C program P consists of a collection of 
declarations such that there exists exactly one definition of a 
function whose name is "main". P's execution begins with this 
function. 

P need not be translated all at once. Typically, components 
of P are kept in separate source //*/£»? that are independently 
translated. We assume the notion of "source file" is atomic 
and therefore provide no definition for it here. 

A compilation unit is a single source file F unless F 
contains preprocessor directives that specify the inclusion of 
other source files as part of the unit. We leave unspecified 
exactly how compilation units are determined, for that is, in 
general, a host-environment-dependent concept not of concern 
here. 

The focus here is only on the semantics of compilation 
units and the semantics of the combined translated results of 
separately compiled units. We shall not discuss the process of 
linl(ing\N\\\z\\ is typically used to prepare the translated results 
for "execution", nor the execution process. The translated 
linked result Is a C program that may be executed i.e. its 
meaning made manifest. 

The reason that separate translation must be addressed is 
that the semantics of a C program when independently trans- 
lated are not identical to those when the components are 
"glued" together in a single source file and translated all at 
once. For example, in each of two separate compilation units, 
the declaration "static int x; " may appear; however, two 
such declarations cannot appear in a single unit. 
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2.8 When is a Program a Program: the Preprocessor 

[conditional conpilation; file inclusion; nacro replacenent] 

A "normal" description of a programming language I 
defines lexical syntax, phrase-structure syntax, constraints, 
and semantics. Text P is a legal program in L (and therefore 
has meaningful semantics) when: (a) P is lexically valid; (b) 
the word sequence defined by the lexical syntax forms proper 
phrases; and (c) the constraints are satisfied. Thus, a 
program's validity can be determined without reference to any 
"processors" that do syntax checking or constraint analysis, 
such as "scanners", "parsers", and "constrainers". 

For C the description cannot be so simple. Part of the 
definition of C includes a so-called preprocessorX\\dX modifies 
the word sequence defined by the lexical syntax before that 
word sequence is subjected to phrase-structure analysis. The 
preprocessor is complex and interacts with the lexical analysis 
in such a way that the only reasonable way to understand 
whether a program is valid is to simulate the machinations o^ 
the processor, at least through phrase-structure analysis. 

Therefore, for the purposes of this document, text P is a 
legal C program if: (a) P is lexically valid; (b) the words as 
transformed\isi the preprocessor form proper phrases; and (c) 
the constraints are satisfied. 

The C preprocessor effects: (a) conditional compilation, 
including and excluding program texts from compilation based 
on the evaluation of Boolean expressions; (b) file inclusion, 
logically substituting for file inclusion directives the contents 
of source files referred to in the directives; and (c) macro 
replacement the transformation of some sequences of words 
into other sequences of words. 

The preprocessor is explained in more detail in Section 
Preprocessor 

The term "preprocessor" is due to its often being a pro- 
gram separate from the C compiler per se, transforming the 
source file before the C compiler analyzes it. However, the 
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definition of the preprocessor component of the language does 
not preclude its incorporation into the lexical analysis phase of 
a C connpiler^ and we know of at least one connpHer that does 
<^p, namely the MetaWare High C ^ Compiler. 
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3 
Concepts 



The concepts described in this section are needed for the 
later description of C relative to its syntax. 

Defined concepts are illustrated by example C programs^ 
even though the syntax of C programs has not been discussed 
yet. Readers familiar with C will find the examples helpful; 
those not familiar can make good use of the examples upon 
second reading, after studying the syntax of C. 

3.1 Name Spaces 

[declaration property set; ordinary, tag, label, and struct and union 
nane spaces] 

Every declaration in C associates a name with a declar- 
ation property set^\y^\T\ a specific declaration name space. 

A name space can be viewed as a mapping taking a name 
into its declaration property set. There are three distinguish- 
ed name spaces in C: the ordinary n^me space, the tagx\m\e 
space, and the ladelname space. There is also a name space for 
each distinct struct and union type, which contains the type's 
member names. 

The explanation of each declaration gives the name space of 
the name declared. The three spaces permit the same name to 
be associated with up to three different property sets. The 
syntactic context of a name always determines which name 
space holds the association. For example, a label name either 
precedes a ":" at the beginning of a statement, or follows the 
reserved word goto; it appears nowhere else. 

The elements of declaration property sets are described 
later in this section. 
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Examples: 






int x; 


/* x: 


ordinary nane space. */ 


struct s { 


/* S: 


tag nane space. */ 


int x; 


/* X: 


nane space of the struct type s. */ 


}y; 


/» y: 


ordinary nane space. ^/ 


L: goto L; 


/» L: 


label nane space. */ 



3.2 Blocks, Origins, Defining Points, and Scopes 

[duplicate declaration] 

The discussion in this subsection does /7^7f apply to the 
member names of struct and union types; the issues of 
blocl<s, origins, defining points, and scopes are irrelevant to 
such names. 

Every declaration is contained in one or more ^/o^Xx which 
are regions of program text. The specific locations of such 
regions are not described here; the description of a construct 
having an associated block contains the description of that 
block. 

Generally, a block inner can be a part of another block 
Outer, in which case Outer is said to conta/n\m^r. The block 
Inner is then called an inner block k^\ Outer, while Outer is 
called a surrounding block ^\ Inner. In general a program 
consists of a hierarchy of nested blocks. 

The innermost block in which a declaration occurs is called 
the orlglnzA that declaration. 

The defining polntoi a name is the occurrence of the name 
In its declaration. 

Every declaration D has a scope. The scope of D is that 
program text in which the declared name N is associated with 
the property set of D. The scope of D is generally the program 
text extending from the defining point of N to the end of D's 
origin, but there are exceptions. The first is when the declared 
name is re-declared in a contained block and in the same name 
space: 
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Suppose that block Outer contains block Inneo and that 
Outer is the origin of a declaration D of nanne N within 
nanne space S. If Inner Is the origin of another declaration 
D' of N within S. then the program text from the defining 
point of N in D' to the end of Inner is excluded from the 
scope of D. 

Other exceptions to this rule are documented with the 
exceptional constructs. 

If the scope of two distinct declarations D and D' of a name 
N in the same name space overlap, this Is known as a duplicate 
declaration o/N, Such duplicate declarations are prohibited. 
This means, for example, that D and D* may not appear in the 
same block; e.g. "int a, a; " Is not allowed. 

However, two declarations of the same name in different 
name spaces Is permitted: "struct s {Int y;} ♦•p; int s;'\ 
for example — the first s Is in the tag name space and the 
second is in the ordinary name space. 

Under certain circumstances, apparent duplicate declara- 
tions are permitted. In addition, certain combinations of non- 
duplicate declarations are prohibited. These situations are 
described in Subsection Independent Translationhe\ovi. 



Examples: 



(a) 


int x; /» X: 


(b) 


Struct X { /*♦ X: 




/* 


(c) 


int x; /* X: 




/* 


(d) 


struct X {...} y;/» x: 


(e) 


} x; /** x: 


(f) 


x: goto x; /» x: 




/* 



ordinary nane space. 

different nane space than in (a); 

hence not a duplicate declaration 

issues of scope, block, etc. 

do not apply to this nane. 

conflicts with (b): duplicate dcln. */ 

conflicts with (a): duplicate dcln. */ 

different nane space than in (a) V 

or (b); hence not a duplicate dcln. */ 



V 
V 
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3.3 Declaration Property Sets 

[node, type, storage class; nodes var, value, fen, typedef; nodes 
struct-tag, union-tag, enun-tag; nodes nenber, field; lvalue, rvalue] 

A declaration property set contains the information abou* 
a nanne gleaned irom its declaration. This set prescribes how 
the name may be used subsequently in its declaration's scope. 
This set is not something a C program manipulates, but rather 
is needed by the reader of a program to understand it in detail. 
The set may be used by a C language processor to check con- 
straints and perform translation. 

The property set consists of up to three "attributes": a 
mocfe. a t)pe^ and a storage class. Generally the mode and type 
attributes are typeset in lowercase boldface. Also, an expres- 
sion has mode and type (but no storage classX even though it 
does not interact with the name spaces. Names in the label 
name space do not have a mode (it is unnecessary), but names 
in the other name spaces have all three attributes. 

The mode is one of var, value, fen, struct-tag, union- tag; 
enum-tag, member, field, and typedef. Modes are used to 
capture the ways in which names can and cannot be used. For 
example, the mode field is used to prevent taking the address 
of a structure bit-field. The mode of a name or expression E 
may be interpreted as f ol lows: 

Mode means 

in the ordinary name space: 

var E may be used on the left side of an assignment. 

value E is legal only on the right side of an assignment. 

fen E denotes the entry point of a function. 

typedef E is a typedef. 

in ti)e tag name space: 
struct-tag E is a struct tag. 
union-tag E is a union tag. 
enum-tag E is an enumeration tag. 

in tite name space for a struct/union type: 

member E is a non- field member of a structure or union. 

field E is a field of a structure or union. 
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These explanations are deliberately inconnplete here; the 
full nneaning of the modes is nneant to be obtained fronn read- 
ing the sections that attribute modes to expressions and names 
•>nd the sections that require certain modes. KR uses the 
c'erms "lvalue" and "rvalue" as modes; in our notation^ rvalue 
is value and lvalue is the the union of the modes var and field. 

Types and storage classes are discussed in the remainder of 
this chapter. 

If a declaration associates a name N with a property set 
containing mode M. type T, and storage class C and within 
name space S, we also say that the declaration "declares N to 
be of mode M, of type T, of storage class C, and within S". We 
may omit any of M, T, C, or S, as appropriate. 

Examples: 

int >cf(); /* X: node vir; f: node fen. */ 
typedef 

struct s { /* s: node struct-tag. */ 

int x; /* x: node miiber. ♦•/ 

int z: 3; /* z: node field. */ 

} y; /* y: node typedef. */ 

enum e {a, b}; /* a,b: fwde value; e: node enun-tag. ^f 

union u {int x; }; /* x: node nenber; u: node union-tag. V 

L: goto L; /* L: no node necessary. */ 

3.4 Values, Types, and Objects 

[vuiilli; tyH rftiwUtitn; sizi ef rtjtct; iittfrtl, flMtiRf. iritlmttic typ«$; 
Si|Md-Int, ttnsiimd-Iiit; SignH-SlMrt-Int VmiinH-SiMrt'lRt; <aiM>; SisuH-Chtr, 
Dnsiinetf-dMr; Signed-lMf-Int, MnsiinH-Lofif-Int; Float, Beoblt, Lttif-Dooble; Void] 

Values are entities upon which operations may be per- 
formed. 

TiT/fis" classify values according to the operations that may 
be performed upon them: a type Is a set of values. 

Objects z^w "contain" values, usually of a single type; at 
different times during the execution of a program an object 
may hold different values. 
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Declarations in C ainnost always declare objects. Some 
objects may have other objects as components. As in other 
languages, when we speak of a var/ab/evie mean a declared 
name denoting an object, since the variable's contents ca 
vary. In contrast, a declared name denoting a function does not 
denote an object and is not spoken of as a variable. 

Since a type is a set of abstract values, we can never write 
down a type in this document, but merely use a word or words 
to denotes type. For example, we use "Signed- Int" to denote 
the type consisting of a subset of all the signed integers. (The 
particular subset is implementation-defined.) 

Values and objects of a given type T are represented in a 
fixed number of storage units; this number is the $ize^\ T. 

The storage unit must be able to contain any value of type 
Signed-Char or Unsigned-Char and Is usually the eight-bit 
byte. It must be possible to express the address of each storage 
unit in the target architecture; these addresses are the values 
of pointer types (described below). 

Basic types. There is a set of basic types in C, and methods 
for denoting new types in terms of basic types. The Table 
below lists the names for the basic types. The two distinct 
subsets, integral dx\^ /A?*?^//?^ comprise the arithmetic types: 

Table Arithmetic types. 

Integra/ types: Floating types: Other: 

Signed- Int Unsigned- Int Float Void 

Signed-Short-Int Unsigned-Short- Int Double 
Signed- Long- Int Unsigned- Long- Int Long-Double 
Signed-Char Unsigned-Char 

Shorthand. Without some shorthand, the phrase "denoted 
by" will appear all too often in this document. For example, 
consider the precise but cumbersome phraseology: "If T1 is 
the type denoted by Unsigned- Int and T2 the type denoted b*' 
Signed- Int, then T3 is the type denoted by Unsigned- Int". 

Hereafter we drop the "denoted by" when the intent is 
clear, and use the denotations as if they were the actual types. 
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After all, the denotations are just the namesi^r the types, and 
in comnnon English usage we do not introduce "the nnan denot- 
ed by Fred" — rather, we introduce Fred. 

Nevertheless, the distinction between types and their spe- 
cification In a C program must be kept clear. In a C program 
one writes "int" to denote the type Signed- Int. However, 
what one writes /snotXhe type, but merely denotes it. 

The difference shows up better In the C phrase "int short 
unsigned": this phrase and In fact any permutation of those 
three words (and possibly Intermixed with a Storage_class) 
denotes the type Unsigned-Short- Int. 

Types, denotations. Because C syntax permits more than 
one way of denoting some types, we have chosen our own type 
denotations; we use exactly one denotation for each type. How 
to denote types In C Is not detailed until the next section. 
Here we discuss briefly the repertoire of basic types. 

There are no values of type Void. Void Is used primarily as 
)e return type of a function returning nothing. 

The type Signed- Int corresponds to a signed Integer. 
Typically, its size is "natural" to the machine's arithmetic 
abilities. 

Signed- Short- Int and Signed-Long-Int are two other signed 
Integer types. The set of values of a Signed-Short-Int is a 
subset of that of a Signed- Int, which Is a subset of that of a 
Signed-Long-Int. These variations on Signed- Ints are provided 
to obtain more efficient or larger integer calculations where 
necessary. Even if an implementation defines Short- Int or 
Long- Int to have the same set of values as Signed- Int, all three 
are nevertheless distinct types. 

Each of the three Signed- Int types has a corresponding 
unsigned type whose size Is the same as the corresponding 
^gned type. The set of non-negative values of a signed type Is 
a subset of that of Its corresponding unsigned type. 
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The values of a Signed-Char are a subset of the values of a 
Signed- Int. The values of an Unsigned-Char are a subset of the 
values of an Unsigned- Int. However, the values of a Signed- 
Char need not be a subset of the values of a Signed-Short-Int; 
likewise with the corresponding unsigned types. Essentially, 
the Char and Short- Int types are two not necessarily related 
integer types shorter than Signed- Int. 

The rules for assignnnent connpatibility presented later in 
this Section require two distinct integral types to have the 
sanne set of values if the two types are of the sanne size and of 
the same "signedness". 

An object declared of type Signed-Char can hold any <CHAR>. 
<CHAR>s specified without the '\ddd' or '\xddd* fornn are 
guaranteed to be non-negative; otherwise, the sign of a <CHAR> 
is inaplennentation-def ined. Unsigned-Char can hold any non- 
negative <CHAR>. 

Float. Double, and Long-Double are f loating(-point) types. 
Any Float value is representable in Double. Any Double value 
is representable in Long-Double. Even if an innplennentation 
defines Float and Double to have the sanne set of values, they 
are nevertheless distinct types; the same holds for Double and 
Long-Double. 

The set of integral values is not necessarily contained in the 
set of floating values, and vice-versa. 

3.5 Denoting New Types 

[constructed ty^s; array and csipaaant typi; iacoaplata typts; paiotar typa; structura 
and unian typas; iiaakar-liU; scalar and aigragata typas; functiooality typas; 
pratotypa and aaii-pratatypa fmctiaaalitias; paraiiatar typas; typa natatioB] 

There are methods for denoting new. non-basic types based 
on existing types; we call these the constructed types. The C 
syntax for denoting these types is given in a later section; here 
we specify our own notation to denote such types. 

If I is an integral value and T any type. [I]:T is an array t^e 
with component type^, and [?]:T is a incomplete array type 
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with component typel. An incomplete array type Is one for 
which the size of the array is unknown. 

If T is a type, *♦! is a pointer i>;c?^with base typel. 

If M Is a Memberjist (see Section Declarations/Tagged 
Types \^x its syntactic definition), Struct{M} is a structure 
type'HxWK member- //stM, and Union{M} is a un/'on typev^Wh 
member-list^. The C language also provides for incomplete 
Struct and Union types, where the Memberjist is not given. 
Such types are denoted by Struct{?} and Union{?}, respectively. 

The types [?]:T (for any T), Structf?}, and Unlon{?} are 
collectively referred to as the incomplete Xy^e^. Incomplete 
types have fewer uses than complete types. Primarily, objects 
of Incomplete types may not be declared,. and the sizes of 
incomplete types are specif ical ly undefined. 

Arithmetic types and pointer types are collectively called 
scalar Xy\i^, and array, struct, and union types aggregate 
types. 



Examples: 








extern int a[][3]; 


/^ a: 


type [?]: [3]: Sioned_int. 


*/ 


double *pd; 


/* pd: 


type •Double. 


*/ 


double *apd[3]; 


/* apd: 


type [3]: -Double. 


V 


double (*pad)[3]; 


/* pad: 


type •[3]: Double. 


*/ 


struct {int x;} *»aps[3]; 








/* aps: 


type [3]:-Struct<int x;>. 


V 



Functionality types. There are four kinds of functionality 
types: those types describing functions. The four kinds fall into 
two classes: the /7/77iV7(^f»functionalities and the non-proto- 
^£» functionalities: 

(a) (?) ->T for T a type; 

(b) (Ti,...Tn) ->T \ 

(c) (Ti,...Tn)p ->T I for T,Ti,...Tn types, n 2 0. 

(d) (Ti,...Tn,...)p ->T / 

The first two kinds represent notions in KR C, and are the 
non-prototype functionalities. In class (a) the function returns 
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values of type J, but the number and types of its paranneters 
are unknown. In class (b) the paranneter number and types are 
known: Ti....Tn (if n = 0. there are no parameters), (b) can 
arise only from a function definition, never from a declaratioi^ 
alone, since any attempt to specify parameter types in a 
declaration alone requires the use of prototype functionalities. 
See Subsection 3. 10 for the distinction between definitions and 
declarations. 

The last two kinds are the prototype functionalities. In 
class (c) the parameter number and types are known, in class 
(d) the trailing "..." indicates that more arguments may be 
passed than there are parameters declared. 

Prototypes are a recent (ANSI) addition to C. They allow 
more secure Pascal -style argument type checking at function 
calls. The constraints and semantics of calls to functions of 
prototype functionality are quite different from those without 
such; see Section Expressions/Function CaU. A declared 
function f has a prototype functionality when the nonterminal 
Abstract_paraineters is used to specify fs parameters; it hai 
non-prototype functionality otherwise (see Section DecJara- 
tions/Function Definitior^. 

Exampies: 

int f1(); /* f1: type (?) -> Signedjnt. V 

int f2(void); /* f2: type Op -> Signedjnt. */ 

double f 3 (unsigned char c, float f); 

/*» f3: type (Unsioned_char.Float)p -> Double. */ 
double f4(unsigned char c, float f){ 

/* f4: sane as type of f3. *♦/ 

} 
double f5(c, f) unsigned char c; float f;{ 

/*» f5: type (UnsiQned_char, Float) -> Double. */ 
} /* Hot sa«e type as that of f3: not a prototype. *♦/ 
int *(»f6(double))[3]; 

/*♦ f6: type (Double)p -> -[3]:»SiQnedjLnt. **J 

Note that compatibility with old C demands rather 
awkward notation to declare an external function taking no 
parameters: "(void)", as in f2 above. This is because 
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"()" alone declares a function whose parameter types are 
unspecif Jed. Declarations like that of f 1 should be avoided. 

Why new type notation. We introduced this new notation 
have an accurate way of referring to types. The syntax used 
in C to specify types is not conducive to easy comprehension of 
the specified type, nor is it appropriate to the specification of 
language rules for types. This new notation borrows symbols 
from C to facilitate readability. 

This new notation also has an advantage over C's notation 
for denoting types in that it requires no precedence or 
associativity rules to understand, nor therefore parentheses to 
override precedence and associativity, and it is unambiguous (a 
grammar for it, which Is implicit in the above rules, is in fact 
LR(0)). See the examples above, some of which contrast C's 
awkward need of parentheses with the clean parenthesis-free 
type notation. 

Type "expressions" constructed with this notation can be 
-*»ad strictly from left-to-right. For example, in the C 
Jclaration "int »f (); ", f has type ( )->*Signed-lnt; in the C 
declaration "int (**f )(); ", f has type «( )->Slgned-lnt. 

The rigor of the notation can yet be improved, since the 
definition of Struct and Union types relies on the syntactic 
notion I1ember_list with no further interpretation of the 
phrases of those categories. But the notation can be made 
completely formal only at considerable expense. 

The tradeoff will be evident later when slightly more com- 
plex rules are necessary for defining type sameness and equiva- 
lence. We appeal to the reader's Intuition that, for example, 
the text of the Member_list is insufficient to determine the 
full type; two Member_lists can be textual ly Identical yet in 
different blocks so type references within the lists may be 
different. 
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3.6 Same Types 

[constructed types; instance of construction] 

Each Instance in C of a constructed type denotes a type 
distinct from any other constructed type. Thus, although two 
type constructions in C may appear identical, they denote 
different types. It is as if each type had as a component its 
"instance of construction". Two types are the same typeW 
they have the same instance of construction. 

For convenience, our formal notation for types does not 
incorporate instance of construction, because once the notion 
of "same type" is formalized, the instance of construction 
concept will be used infrequently. However, a C language 
translator must encode the instance of construction in its 
internal representation of types. 

Examples: 

struct s {int )cy;} x1; 

struct {int y, z; } x2; 

struct s x3; /*♦ A use, not a definition. •♦/ 

char *x4, *^; 

int x6[10], x7[10]; 

void V() { 

struct s {int x,y;} x1; 

} 

There are three distinct declarations of Struct types; as 
specified in Section Declarations/Tagged Types, the third 
line references the type denoted by the constructor on the 
first line, so that x3 and xl are of the same type. Even 
though the first and last declarations appear textual ly 
Identical, they denote distinct types because they have 
different Instances of construction. x4 and x5 are also of 
distinct types: two distinct »»Signed-Char types. Similarly, 
x5 and x7 are of two distinct [1 Q]:Signed- Int types. 



V. 1 1 . 01 . 85 © 1984-85 HetaWare Incorporated 



Concepts page 3-13 

3.7 Equivalent Types 

[sane variable; sane types; sinilar types; independent translation] 

The requirement of identical instance of construction In 
;the concept of same type leaves a major problem unsolved: 
how to specify type security across independent translation. 
For example^ rules explained later state that it is possible to 
declare a variable X in source file F1 and a variable X in file F2 
and have them denote the same object, thus: 

FHeF1: FileF2: 

int *X; int *X; 

The two Xs are of distinct ♦•Signedjnt types, since the 
instances of construction of the types are different. How can 
the "same object" have two distinct types? 

The solution we propose is to require only that distinct 
declarations of the "same variable" be associated with 
"equivalent" types rather than the "same type". Two type 
denotations T and T' denote equivalentX^^^ if: 

1. T and T' are of the form Struct{MK and the corresponding 
types of each member in M are equivalent; or 

2. T and T* are of the form Union{M}, and the corresponding 
types of each member In M are equivalent; or 

3. T and T' are "similar" types. 

Two types T and T* are similarW types S and S* are similar and 

1 . T and T' are the same type; or 

2. T is of the form "S and T* of the form «S'; or 

3. T is of the form [V]:S and T' of the form [V]:S'; or 

4. T Is of the form [?]:S and T' of the form [?]:S'; or 

5. One is of the form (?) -> S and the other (Ti,...Tn) -> S'; or 

6. T = I -> S and T' = I' -> %\ and I and I* are of the same 
form, i.e. one of the parameter forms of the four function- 
ality forms used in Subsection 3.5 above, and the corres- 
ponding parameter types are similar. 
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The reason for the "similar" subcategory of type equivalence 
is that similarity can be applied within a single C compilation 
unit, whereas the additional notion of type equivalence is used 
only for independent compilation. 

Examples: 

typedef char T; 
struct s {T x,y;} x1; 
void V() { 

typedef int T; 

struct s {T )cy;} x2; 

struct s2 {T >cy;} x3; 

char *^4, ♦♦xS; 

int x6[10L x7[10]; 

int f1(); 

int f3(int >c int y); 

int f3(>cy) int x,y; {-.} 

int f4(int a* int b) {-.} 

x1 and x2 are not^i equivalent types: the two Struct{T 
x,y;} typiBs are not equivalent — in one case T refers to the 
type Char and in the other the non- equivalent Signed- Int. 

x2 and x3 are of equivalent types since the tags s and s2 do 
not figure in the type denoted by the declarations. 

x4 and x5 are of distinct but equivalent (and similar) 
*Signed-Char types. 

x5 and x7 are of distinct but equivalent (and similar) 
[lD]:Signed-lnt types. 

f 1 and f2 are not of equivalent types, but f 1 and f3 are, and 
f2 and f4 are. 

The KR definition of C does not recognize the problem of 
type security across independent translation. X3J11 is still 
deliberating it at the time of this writing. All C translatorl 
known to this author do not type-check across independently 
translated files, with attendant risk to the programmer if he 
provides inconsistent declarations. 
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3.8 Lifetimes 

[global and local lifelines; Conpound^statenent; storage classes] 

Objects manipulated In a C program have two different 
linds of "lifetimes": global and local. 

An object of global lifetime exists and retains its value 
throughout the execution of the entire program. 

An object of local lifetime \% created upon each entry Into 
the Compound_statement in which the object is declared and is 
discarded when the Compound^statement is exited. By 
"created" we mean only that the storage for the variable is 
allocated^ but not that the variable is provided with any initial 
value(s). Storage is allocated even if the Compound^statement 
is entered "abnormally"^ through a jump transfer of control 
(e.g. goto). 

The lifetime of an object is determined by its storage 
class, as discussed in the next subsection. 

Examples: 



int x; 
void f { 
int x; 

{ 
int y; 


/* X: global lifetine. 
/* f: global lifetine. 
/* X: local lifetine. 




/* y: local lifetine. 


*/ 


L: V = 3; 


/^ Storage for y is always allocated 
/* uhenever we arrive at L, 


-/ 
*/ 


goto L; 

} 


/♦♦ even through wans of this goto. 


-/ 



3.9 Storage Classes 

[autoMatic, static, and typedef storage classes; static-private, 
static-export, and static -iRport] 

There are three storage classes: automatic^ static^ and 
fypedef. The static storage class is further subdivided into 
static- private, static- export and static- import, which are 
mutual ly exclusive and jointly exhaustive of static. 



v. 1 1 . 01 . 85 © 1984-85 MetaUare Incorporated 



Concepts 



page 3-15 



An object with the static storage class has global lifetime; 
an object with the autonnatic storage class has local lifetime. 

There are no objects of the typedef storage class, anj^ 
therefore no lifetime issues. This class exists only for defini 
tional convenience. 



/*• X: static-export => global lifetiw. *♦/ 



Examp/es: 

int x; 

extern int z; /*♦ v. static-inport => global lifetine. V 

static void f (){ /* f: static-private «> global lifetine. */ 

int X; /** X: autofiatic => local lifetine. *•/ 

} 
typedef int T; /*• T: typedef => lifetine irrelevant. V 



3.10 Declarations and Definitions 

[type; storage class; storage allocation] 

A declaration in C announces the properties of an identifier 
N, e.g. its type and storage class. Additionally, a declaratlor 
may be a cfef/mt/onQi N; not all declarations are definitions. 

Intuitively, definitions cause storage to be "allocated" for 
variables and the code body of functions to be specified. 
Exactly those declarations having storage class static- export, 
static-private, or automatic are definitions. 



Examples: 

int x; 

extern int z; 
static void f (){ 
int x; 

} 
typedef int T; 



/* X: Static-export => definition. V 

/*• z: static-inport => not definition. */ 

/* f: static-private => definition. */ 

/* X: autonatic => definition. V 

/* T: typedef => not a definition, **/ 

/* but irrelevant for typedef s since **/ 

/** no storage is allocated for T. */ 
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3.11 Independent Translation; Duplicate Declarations 

[sharing daclaratims; separata caiipilatiM wits; static-iNport static-export, 
mi static-private; storage-class; infornatien sinilar; iaforiiation inaeasing] 

Generally, separate connpjlation units of a C program 
'share" declarations of data and functions — if there were no 
sharing, there would be no purpose for combining all the units 
into the single program. Sharing is achieved when two distinct 
declarations denote the same entity, as described in this 
subsection. 

First, there are restrictions placed upon distinct declara- 
tions of the same name N appearing in distinct compilation 
units. Under the restrictions, the distinct declarations denote 
the same object or function and therefore achieve sharing 
among units. 

Second, certain apparent duplicate declarations are per- 
mitted in a single compilation unit, "extern int a[]; ... int 
alio];" exemplifies a common case, where the former de- 
claration is typically contained in an included source file. We 
^ay "apparent" because the special rules described below 
specify that an apparent duplicate does not itself declare, but 
instead modifies, the previous declaration, so there is yet a 
single declaration. Therefore we can always speak of a single 
compilation unit having a single declaration for a name N in 
the outermost block. 

The description of the duplicate declaration rules is involv- 
ed. The reader may find it profitable to go through the rest of 
this manual in the frame of mind that a C program is a single 
compilation unit, then return here for multiple-unit issues. 

Denotation of the same entity among separate compil- 
ation units. Consider all declarations in a C program of a 
given name N within the ordinary name space such that the 
storage class of each such declaration Di is static- import or 
static-export. All the Di denote the same entity if the 
following two conditions hold: 
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(a) the types specified in the Di are equivalent, except that 
here type [?]:T is considered equivalent to [V]:T for any 
V, in any non- function declaration, and 

(b) exactly one of the Di declares N of storage class static 
export. 

Note that this pernnits one or more static-private declara- 
tions of N in a progrann. Such declarations do not interact 
with other declarations of N of static storage class. 

Examples: 

CompifationUnit 1: 

extern int N[]; /♦♦ Static-import. ♦♦/ 

extern int N[]; /♦• Static-import. V 

int N[2]; /•♦ Static-export. ♦♦/ 

Compilation Unit 2: 

extern int N[]; /* Static-import. V 

Compilation Unit J: 

static char N; /♦♦ Static-private. */ 

void F() { 

extern int N[]; /* Static-import. V 

extern int N[]; /* Static-import. */ 

} 

Annong these three units there are only two distinct enti- 
ties nanned N; one is declared of type Char in Unit 3 and the 
other is declared six tinnes In the three connpilation units. 
The following ^^3i////i7/7^/declarations are /7^7^al lowed: 

Compilation Unit 4: 

void GO { 

extern float N; /^Static-import, but wrong type. V 

} 
Compilation Unit 5: 
int N; /♦♦ Duplicate static-export. V 
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Compilation Unit 6: 

extern int N[3]; /* [3]:Signed_Int not equi- V 

/* valent to [2]:Signed_Int. ♦♦/ 

The single static-export declaration D nnay be viewed as 
che "seat" of the declared entity. The static- innport declar- 
ations nnay be viewed as nnerely referencing D. (In fact, innport 
and export declarations are comnnonly innplemented this way.) 

There nnay be at nnost one initialization specified for a set 
of nnultlple declarations. This restriction Is Innposed in Sec- 
t i on Declarations/Non- Function Definitions on i n i t i a I izat i ons 
where only static-export declarations are allowed to have ini- 
tializations, and the rules here permit only one static-export 
declaration. 

Note that the rules require a definition of storage class 
static-export for an identifier. Alternatively, sonne C lan- 
guage processors weaken rule (b) above to read 

(bO at nnost one of the Di declares N of storage class 
static-export. 

These processors create the definition innplicitly when the 
translated results for the independently translated connpil- 
ation units are connbined to form an executable program. 

Rule (b) as it stands necessitates an aspect of program un- 
reliability, in that at least two textual ly different declara- 
tions for the same name are required, one by the "provider" of 
the name (the definition declaration), and the other by any 
"user" of the name: 

Provider: User: 

int ♦»X; extern int *X; 

Changing X's type requires modifying two distinct declara- 
tions; if one modification is forgotten, the program is no long- 
y correct. On the other hand, with rule (b'), the distinction 
jetween user and provider is only In the mind of the program- 
mer, and both may include the identical declaration of X, so 
any change requires only the change of a single declaration: 
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Shared declaration. 
Provider: User: in fiie "X. def: 

tinclude "X. def ' tinclude -X. def int -X; 

Duplicate declarations in a single compilation unit. An 

apparent duplicate declaration D of a nanne N is allowed in the 
presence of a previous declaration D* of N in the sanne scope, 
provided certain conditions are satisfied. Furthernnore D may 
"update" the declaration of D, i.e. revise its type or storage 
class so that from the defining point of N in D* through the the 
remainder of the scope of D, N is associated with a modified 
property set. 

Example: 

extern int *(*b[ ])[ ]; 

extern int *(*b[ ])[5]; 

int *(*b[3])[ ]; 

The first line declares b of type []:**[]:»Signed-lnt (an array 
of pointers to arrays of pointers to Signed- Ints). Thr 
second supplies the size of the second [J, giving []:**[5p 
"Signed- Int as the "updated" type of b. After the third 
declaration^ b Is of type [3]:**[5J:*Signed-lnt, and its stor- 
age class is "changed" to static-export. 

Here are the rules concerning would-be duplicate declar- 
ations. Assume declaration D declares N of mode M, type T, 
and storage class C, and apparent duplicate declaration D' 
declares N of mode M', type T', and storage class C*. D' is not 
a duplicate declaration of N if and only if either: 

(a) M and M' are var, C and C individually are static- 
import or static- export, and either T and T* are similar 
or T' is "information similar" to T (defined below); or 

(b) M and M' are fen and T and T' are similar. We further 
require that two distinct declarations of the sam^ 
function must have Identical parameter names, if given. 

In case (a). If T' Is "Information Increasing" — where 
information similarity holds yet T* has "more information" 
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than T, T* is "updated" to reflect the increased information. 
The increased Infornnation connes in the fornn of array bounds 
whose size are unspecified in J, I.e. the updating consists of 
changing an incomplete []:... type to a completed [V]:... type^ 
/here V is the new information. Furthermore, if C was 
static- Import and C static-export, C Is changed to static- 
export so that the net effect is that C Is exported. Note that 
neither C nor C can be static- private; e.g. "extern int ec- 
static int a;" is Illegal. 

In case (b), if D* is not part of a function definition. It is 
essentially Ignored. If D' is part of a function definition, it 
"replaces" the declaration D of N for the remainder of N's 
scope. See the examples at the end of this subsection. 

Type T* is defined to be information similar \^ type T in 
the same way they are defined to be similar, except that in 
cases 2, 3, and 4, S' Is Information similar to S rather than 
just similar, and we need the addition of the following case 4': 

4*. T Is of the form [?]:S and T' of the form [V]:S'; In this case 
T' Is said to have more in forma tionXh^n T, \^iz. the array 
bound. 

Example: Revisiting the example given above: 

extern int ♦•(♦♦b[ ])[ ]; 

extern int ♦•(•♦bi ])[5]; 

int ^(-b[3])[ ]; 

the type of the second declaration Is Information- increas- 
ing with respect to the type T of b determined in the first 
declaration, so that T is updated to reflect the [5] bound. 
The type of the third is likewise Increasing with respect to 
(the updated) T, so that T is updated again to reflect the [3] 
bound. Also, the storage class of b is altered to static- 
export. 



V. 1 1 . 01 . 85 © 19B4-B5 HetaWare Incorporated 



Concepts 

Examples: (duplicate function declarations) 



page 3-22 



int f (); /* No parn infornation. 

int f (int); /♦♦ Illegal: not sinilar to first. 

int f (float r) { /* illegal: not sinilai to first. 



/* Parn type and nane given. 

/* Illegal: float != int. 

/♦♦ Illegal: j !=* i. 

/♦* Definition replaces first dcln of g. 



} 
int g(int i); 
int g(float); 
int g(int j); 
int g(int i) { 

> 
int h(); /♦♦ No parn infornation. 

int h(r) float r; { 

/♦♦ Definition replaces first dcln of h. 

} 



V 






*/ 
*/ 



3.12 Compatible Types 

[sinilar types] 

Where two different types participate in an expression, 
they nnust sonnetimes be "conripatible". See, for example, the 
?: and «= operators in Section Express/onssxx^ the definition of 
assignment compatibility below. Compatibility is like "simi- 
larity" except in allowing one exception: pointers to non- 
functions can be mixed with pointers to Void. 

Two types are compatible \\ they are similar, or one is 
"Void and the other of the form **S, where S is not a func- 
tionality type. 



Examples: 

int *>c *y; 
void *2; 
int ***ppi; 
void ♦♦♦♦ppv; 



I* Types of X and y are conpatible, since sinilar. ^/ 
/* Types of x and z and of y and z are conpatible. *♦/ 

/* Types of ppi and ppv are not conpatible. * ' 
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3.13 Assignment Compatibility;Arithmetic Conversions 

The notion of assignment compatibility is used to explain 

the constraints and semantics of the C assignment operators 

nd function-call operator. In the context of those operators^ 

arithmetic conversions can take place when certain types are 

not the same. 

Intuitively, type R is assignment-compatible with type L if 
"Vl = Vr" is a valid assignment expression, where Vl is an 
object of type L and Vr is a value of type R. Below are the 
rules for assignment-compatibility. 

The semantics of assignment permit potential conversion 
of Vr to Vr* in preparation for storing into Vl. In all cases 
except where R and L are integral types, the semantics of 
assignment are undefined when Vr' is a value not representable 
in type L. The semantics of converting Vr to Vr* are included 
in the rules below. 

Constraints and Semantics 

Type R Is assignment-compatible with type L if one of 
these three rules apply: 

1. R and L are the same type T, and T is not an incomplete 
type. Semantics: Vr' = Vr. 

2. R and L are compatible pointer types. Semantics: Vr' = Vr. 

3. R and L are distinct arithmetic types. Semantics: 

a. Both R and L are integral types. 

Let Wr be the width of R and Wl be the width of L. Let 
Sr be the sign (either "signed" or "unsigned") of R and 
Sl the sign of L. Consider the cases: 

Wl > Wr : the conversion truncates bits. 

Wl < Wr : the conversion preserves value. 

Wl = Wr : (two sub- cases) 

Sl = Sr : the conversion preserves value. 

Sl ! = Sr : the conversion is bit-preserving: the bit 
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pattern of Vr is stored into Vl. Value is 
preserved if and only if Vr is a value in R. 

b. R is a floating type and L an integral type. 

If Vr is non-negative. Vr' is the largest integer not 
greater than Vr; if Vr is negative, whether Vr* is the 
largest integer not greater than Vr or the snnallest 
integer not less than Vr is innplementation-defined. 

c. R is an integral type and L a floating type. 

Vr' is the floating value In L nearest Vr. If there is no 
unique nearest value, the result is I m piemen tat i on - 
defined. If Vr is outside the range of values of L the 
result is undefined. 

d. R is Float and L Double. 
Vr' = Vr. 

e. R is Double and L Float. 

Vr' Is Vr rounded to the nearest value in R. If there is n 
unique nearest value, the result is innplennentation- 
defined. If Vr is outside of the range of values repre- 
sentable in U the result is undefined. 

Examples: Assume that long ints are wider than ints and 
that double has more range and precision than float. 

int *p1,*p2; 
struct {int x;} sti; 
struct {int x;} st2, st3; 

int i; long int 1; float f; double d; unsigned u; 

pi « p2; /* Leoal. */ 

Sti = st2; /* Illegal. */ 

st2 - st3; /* Legal. V 

i = 1; /** Conversion truncates. **/ 

1 = i; /* Conversion preserves value. *♦/ 
u = 1; /* Conversion preserves bits; nay preserve value. *' 

f = i; /* Value nearest i in Float is stored in f. ♦♦/ 

d = f ; /* Exact value stored. */ 
f « d; /** Value nearest d in Float is stored if it exists. ♦*/ 
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3.14 Integral Widening Conversions 

[vithnetic convirsions; vnsignidntss-prisirvinfl vtrsus valni-prisirving] 

Many contexts require type Signed- Int or Unsigned- Int and 
"widen" any shorter integer types to one of these types. The 
widening is defined as follows: 

Widen(T) = 

if T is Signed-Char or SIgned-Short-Int 
then Signed- Int 

else if T is Unsigned- Char or Unsigned- Short- Int 
then if the size of T is the sanne as that of 

Unsigned- Int on the target architecture 
then Unsigned- Int 
else Signed- Int 
else undefined. 

4.2BSD provides slightly different widening: unsigned types 

always widen to Unsigned- Int. This rule, often called "unsign- 

dness- preserving" as opposed to the "value-preserving" Widen 

defined above, produces quite a few surprises, as illustrated by 

the following C text: 

void f p { 

unsigned char c = getcharO; 
if (c - '0' < II - '0' > 9) 

printf ("Non-digit. \n-); 
} 

In 4.2BSD "c - '0' " is never negative, since it is an unsign- 
ed type (see the next Subsection for combination of operands In 
'-')/ so the first test always fails. In KR, there is no Unsigned- 
Char or Unsigned-Short- Int type so Widen agrees with KR. 
X3J1 1 also uses the widening rules of Widen. 
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3.15 Combination of Operand Types 

[arit/inetic conversions] 

Binary operators may operate on values of different types 
When this happens, generally both values are converted to a 
common type, which is the result type of the operation. The 
function Common(Ti,T2) specifies the common type T of two 
operand types Ti and T2 that are both arithmetic types. It is 
defined as follows: 

1 . An implementation may employ either rule (a) or (b): 

a. If either Ti or T2 is Long-Double, T is Long-Double; 
otherwise, if either Ti or T2 is Double, T is Double; 
otherwise, if either is Float, T is Float. 

b. If either Ti or T2 is Long-Double, T is Long-Double; 
otherwise, if either Ti or T2 is Float or Double, T is 
Double. 

2. Or, If one is Unsigned- Long- Int, T is Unsigned- Long- Int; 
or, if one is Signed- Long- Int, T is Signed- Long- Int; 
or, if one is Unsigned- Int, T is Unsigned- Int; 

or, if one is Sighed- Int, T Is Signed- Int; 

otherwise, T is Common(Widen(T1), Widen(T2)) 
(widenings guarantee that one of the above cases applies). 



3.16 Expression Evaluation: Side Effects, Sequence Points 

[conna operator] 

The semantics of an expression is two-fold, involving the 
production of a value, called the evaluations^ the expression, 
and potential "side effects". 

A side effect \% an aspect of an expression's semantics that 
need not occur during the evaluation. However, If an expression 
is evaluated, any associated side effects must have taken place 
by certain points called sequence points. Thus, side effect? 
may occur any time from the Inception of the evaluation of 
the expression up to the next sequence point. The term and 
concept of a "sequence point" are borrowed from X3J1 1 . 
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The end of execution of any statement or declaration is a 
sequence point. This nneans that by the end of the execution of 
the statement or declaration, all pending side effects must 
have occurred. 

Sometimes the end of the evaluation of an expression is a 
sequence point. This means that by the end of the evaluation of 
the expression^ all pending side effects must have occurred. 

In Section Expressions'^^ specifically note which expres- 
sions have side effects, and in any section where an expression 
is used we specifically note if its evaluation is a sequence 
point. In most cases the evaluation of an expression contained 
within a statement is a sequence point. 

Example: There are two side effects in the expression 
"i++ + 3++": the first Increments the variable i, and the 
second the variable j. However, the side effects need not 
occur during the evaluation of the expression or during the 
evaluation of the subexpressions i++ and j++. But after the 
execution of the statement "k = i-»-+ + j++;", the side 
effects must have occurred, so a use in a subsequent state- 
ment of i or of j must access the incremented value. 

In "k - i-»-+ ■»• 3++;", there is no question what k will be 
assigned, assuming the values of i and j are known. 

Example: But consider the more interesting case: 

int a, b, c,k, i « 0; 

k = (a = i++) + (b = i++) + (c = i++); 

An implementation is free to evaluate the three assign- 
ment expressions in any order (see Section Expression^: 
assume for the moment it is left-to-right. What one 
might expect is that a is assigned Q, b 1, and c 2. But since 
the incrementation side effects can be delayed to the end of 
the expressions, all of a, b, and c can be assigned D. Thus k 
can take on any of the values D, 1,2, or 3, depending upon 
when side effects occur. 
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Example: Introducing sequence points with a connnna 
operator can eliminate uncertainty. Consider: 

int a, b, c, k, i «= 0; 

k = (a = (i++,i-1))+(b = (i++, i-1))+(c = (i++,i-1)); 

Here^ independent of the evaluation order of the assign- 
nnent subexpressions, the values assigned will be D, 1, and 2, 
so k will obtain the value 3. But It is still not known which 
of a, b, and c obtain the value 0, 1, and 2, since the order of 
evaluation of the operands of + is unspecified. 
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4 
Lexicon 



4.1 Character Set • 

[target and host character set; string terninator] 

Two sets of characters are Implementation-defined: that 
interpreted by the target machine (the target seX), and the 
hastseX in which C program text is written. The distinction 
matters for the string and character words that are written 
with the host set and translated into the target set. 

A character whose representation has all bits zero must 
exist in the target character set^ representing the character 
used to terminate strings. 

The host character set must contain the following charac- 
ters: the space character: characters representing audible 
alert, backspace, horizontal tab, new line, vertical tab, form 
feed, and carriage return; the 52 uppercase and lowercase 
characters of the English alphabet; the 10 decimal digits; and 
the following 29 graphic characters: 

! "#%& •()*♦ + ,-./:; < = >?[\] "_{ I }~ 

4.2 Line Splicing ■ 

[end-of-line; "\"] 

C program text may be divided into a sequence of lines. 
Each line is terminated by what is designated in the grammar 
below as an "Eol", for end-of-line. The host environment may 
terminate lines with a special character, by keeping track of 
the record length of each line, or by some other technique. 

No matter how this is done, each line that ends with the 
character "\" is considered to be "spliced" with the next line, 
as if the line terminator were not present. This permits any C 
word to be longer than a single line. For example: 
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This is eQuivaient to 

char *s = "a long\ char *s = "a longstring"; 

string"; 

short_id = a_longer_icl\ short^id = a__longer_identif ier; 

entif\ 

ier; 

/* This is a \ /* This is a comment. V 

comment. V 

X = \ X = 3; 

3; 

Line splicing is not formally treated in the lexical gramnriar^ 
even though It Is possible, because It would increase the gram- 
mar's complexity out of proportion to its importance. 

Discussion 

Line splicing is not a part of KR or 4.2BSD. There, \ is used 
only for continuing long strings to the next line. 

X3J1 1 decided to generalize the construct so that it could 
always be used to overcome line length limitations on some 
operating systems. 

Although it will rarely be used by programmers for any- 
thing other than continuing strings, it may simplify program- 
generating programs. 

4.3 Preprocessor and Lexicon ■ 

[line boundaries] 

Part of the definition of C includes a so-called preprocess- 
or \\\h\ was introduced In Section Notation^L^ effecting condi- 
tional compilation, file inclusion, and macro substitution. 

The conditional compilation aspect of the preprocessor 
necessitates two distinct lexical descriptions of C source text: 
that text excluded from compilation, and that text included in 
compilation. These two descriptions are contained in the single 
lexical grammar presented here. 
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The preprocessor is the only part of C where line boun- 
daries play a significant role. Comnnands to the preprocessor 
are ternninated by line boundaries, and conditionally connpiled 
text consists only of complete lines^ not partial lines. 

The preprocessor lexical conventions do not fit well with 
the rest of the C language, so a substantial part of the lexical 
grannmar is devoted to the preprocessor. Much of this part, 
and the sennantics of the preprocessor -~ i.e. the rules and 
effects of conditional compilation, file inclusion, and macro 
substitution — are described in Section Preprocessor, 



4.4 Included and Excluded Text ■ 

Syntax 

scanner C_lexioon: 

C_lexicon -> Text; 
Text -> (Words Line^end)* (Control_line Text)? 
-> \Soanning Skipped_lines Control_line Text; 

An overall C program, on the lexical or word level, is one 
of two forms of Text: Text that is included in compilation 
(the first alternative), or Text that is excluded from 
compilation. 

Included Text consists of a sequence of lines each of which 
contains Words. This sequence of lines is terminated by either 
the end of the program or a Control_line (preprocessor direc- 
tive) followed by more Text. 

Excluded Text consists of a sequence of Skipped_lines. 
That is followed by a Control_line, then more Text. Control^ 
line is needed after Sl<ipped__lines so that It will be included 
rather than skipped. 

Whether to include or exclude text is determined by the 
preprocessor and is described in the grammar by "\Scanning". 
"\Scanning" in the second rule for Text means to use that rule 
if /7^7/^scanning, i.e. if skipping. 
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The complexity of the grammar at this level is due entirely 
to the line orientation of the preprocessor. 



4.5 Vords 

Syntax 

Words -> Word*; 

Word -> String | Char | Number | Identifier 

I Delimiter | Punctuator j Operator | Comment; 

The Words of C are Strings, Chars, Numbers, Identifiers, etc. 



4.6 Identifiers ■ 

Syntax 

Identifier-> Id_text =>'<IDENTIFIER>'; 

Id_text -> Letter (Letter | Digit)*; 
Letter -> 'A'.-'Z* | 'a'..'z* | '_' ; 

The nonterminal Id^text is used also in describing Control, 
lines and hence cannot be back-substituted. 

Constraints 

Each character in an Identifier stands for itself, and 
distinction is made between upper and lower case. Thus the 
Identifiers "abc" and "ABC" are regarded as different: two 
Identifiers are the same only if they consist of exactly the 
same sequence of characters. There is no constraint on the 
length of an Identifier. 

Semantics 

The text of an Identifier has no semantics at all. Identi- 
fiers serve only to relate declarations of things with their 
subsequent uses; an executing C program deals only with the 
declared things and has no need for Identifier texts. 
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Discussion 

KR specifies that only the first eight characters of each 
Identifier are significant. In addition^ linkers on sonne ma- 
chines accept nannes of limited length. 4.2BSD permits names 
of unlimited length. X3J11 requires an Implementation to 
treat as significant the first 31 characters of each name not 
having static-export or static- import storage class. 

4.7 Numbers ■ 

r<IMTEGER>, <OCTAL>, <HEX>, <FLOAT>; Signed-Int, Unsigned-Int, 
Signed-Long-Int, Unsigned- Long- Int] 

Syntax 

Number -> Integer | Octal | Float | Hex ; 

Integer -> 'r..*9' C '? Digits)? Integral.suf fix? 

->'<INTEGER>'; 
Octal -> '0' (•_•? Oigits)? Integral.suffix? 

->*<OCTAL>*; 
Hex -> '0' ex* I 'x') Higits Integral_suffix? 

->*<HEX>'; 
Float -> Mantissa Exponent? Float_suffix?=>'<FLOAT>* 
-> Digits Exponent Float_suffix?«>'<FLOAT>'; 

Mantissa-> '.' Digits | Digits \Dot_dot '.' Digits?; 
scanner Dot_dot: Dot_dot -> '.' '.'; end Dot__dot 
Exponent-> ('E're') (' + • I'-')? Digits; 

Integral_suffix 

-> 'u* '1'? I '1' 'u'? I 'U* 'L'? I 'L' 'U'?; 
Float_suffix 

-> ;L' I •!• I 'F' I 'f •; 

Higits -> Higit+ list •_.'; # _ is non-standard. 

Higit -> •0'..'9' I 'AV-'F' | 'aV-'f ; 

Digits -> Digit+ list '_'; # _ is non-standard. 

Digit -> •Q'..'9' ; 

Oigits -> Oigit+ list '_•; # _ is non-standard. 

Digit -> 'O'..'?' ; 
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The notation "\Dot_clot" indicates that Digits followed by 
'. ' is a Mantissa only when what follows the Digits Is notd^ 
Dot_dot, which is a scanner for '. ' '. '. This disannbiguates 
the construction "case 1..2:" pernnitted in a switch 
statennent. 

Four forms are described: Integer, Octal, Float, and Hex. 

As nnentioned in Section Notation the longest possible 
interpretation prevails: therefore "12" denotes the Number 12 
instead of the Numbers "1 " and "2". 

Constraints 

The type of an <INTE6ER> is Signed- Int unless Its value is 
not a Signed- Int value, in which case it is Signed- Long- Int, but 
with the following exceptions: If the Integral_suffix 'u' or 
'U' is employed, its type is the unsigned variety of the type 
just determined; and if 'l' or 'L* is employed, the type is the 
long variety of the. type just determined. Thus "I23ul" is of 
type Unsigned- Long- Int. 

If a <HE)(> or <OCTAL> constant has a Signed- Int value, its 
type is Signed- Int; otherwise, if it has an Unsigned- Int value, 
its type is Unsigned- Int; otherwise. If it has a Signed- Long- 
Int value, its type is Signed- Long- Int; otherwise Its type is 
Unsigned- Long- Int; Exception: the use of the Integral_suf f ix 
modifies the type just determined in the same way as for 
<INTE6ER>, explained in the prior paragraph. 

The "value" of a constant is defined in SemanticsbQ\ovf. 

The type of a <FLOAT> is Double, unless it is suffixed by '1' 
or 'L', In which case It Is Long-Double, or by 'f or 'F', in 
which case it is Float. 

Example: Oxffff on a machine with two-byte Unsigned- 
Ints and four-byte Unsigned- Long- Ints is the Unsigned- Int 
value 65_535; 0x10000 is the Signed-Long-lnt value 65_536; 
0x7fff_ffff is the Signed-Long-lnt value 2_U7_483_647 and 
Ox8000_0000 is the Unsigned- Long- Int value 2J47_483_648. 
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Semantics 

Underscores have no significance in Numbers. 

Integers are interpreted in base 10. 

Octal numbers are interpreted in base 8. 

Floats are interpreted in the standard fashion. The letter 
•e* or 'E', if present, means "times ten-to-the-power-of" 
the (optionally signed) base- 10 integer after the 'e* or 'E*. 

The characters following the 'x' or 'X* in Hex are inter- 
preted as being in base 16. The letters 'A* through 'F* (or 'a* 
through 'f ) denote the values lOio through 15io. 

Discussion 

Underscores in Numbers are an extension (from Ada) over all 
C definitions and Implementations known to us. They are 
allowed so that long numbers can be broken up for ease of 
reading. They may be used as a replacement for comma to 
separate thousands: 3_434_112, for example. Following Ada, 

High C disallows such forms as 1 to denote the integer 

1 : each underscore must appear between two digits. 

In KR and 4.2BSD, the digits 8 and 9 are permitted in an 
octal constant and have values 10b and 1 1b* respectively. Both 
X3J1 1 and High C disallow such. 

The Integral_suffix and Float_suffix appear only In 
X3J1 1 and here, 'f or 'F* can be used to prevent arithmetic 
operations from being performed in Double precision in the 
presence of a constant; see Section Expressions. But note that 
it cannot be used to pass a Float constant as a Float parameter 
instead of a Double in the absence of a function prototype, 
since in "gd.Of);", if there is no prototype for g, 1.0 is 
passed as Double. See later discussions on parameter passing 
and function definition. 

At one time the ". . " word was allowed by X3J1 1 for spe- 
cifying ranges in a case statement. It was discarded because 
the committee felt that the task of preventing "1..2" from 
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being recognized as two Floats (expressed by the \Dot_dot in 
the grammar) was distasteful. There is no inherent ambiguity 
in the language definition, since on the phrase-structure level 
it is not possible for two Floats to be adjacent. Therefore 
"1. .2" must a/n^aysbe "1", ". . *\ and "2" in a legal program. 

Machine dependencies 

The range and precision of real numbers are machine 
dependent. 



4.8 Strings and Characters 



r<STR]NG>, <CHAR>; octal, hexadecinal in strings and characters; 
Signed-lnt; "\"; ASCII; arrays] 

Syntax 

String -> '"• DQchar* "" =>'<STRIN6>'; 

Char -> •'" SQchar '•" =>'<CHAR>'; 

DQchar -> Any-'\*-"*' | 'V Special ; 

SQchar -> Any-'\*-* • * ' | '\' Special; 

Special -> 'a* | 'b' | 'f | 'n' j 'r* | 'f | W 

I IVI I (Ml I fill 

-> Digit (Digit Digit?)? # Octal. 

-> 'X* Higit (Higit Higit?)?; # Hexadecimal. 

We describe two words here: the character Char and string 
String. In both, each character in the target character set is 
represented by a character in the host character set or by an 
octal or hexadecimal escape sequence. 

Any character the user can type at the terminal may appear 
within a String or as a Char. 

Constraints 

Each <CHAR> has type Signed- Int. Each <STRIN6> has type ♦♦T, 
where T is the type of c in "char c; *\ except when appearing 
as an Initializer of an array or as an argument to sizeof, when 
it has type [V]:T, where V is the number of characters in the 
string; see Sections Expressions/sizeofdx\^ Deciarations/Non- 
Function Definitions. 
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Semantics 

Char. The enclosing apostrophes for a Char have no meaning 
themselves, but merely delimit the enclosed character. The 
value of a character is the numerical value of the quoted 
character in the target machine's character set. 

Note that backslash (\) is not permitted as a single enclos- 
ed character. When \ appears after the first apostrophe, the \ 
itself and the character following it together have one of the 
meanings indicated in the table below. (The ASCII value 
column is applicable only when the target character set is 
ASCII, and is provided here for convenience.) 

Pair Meaning ASCJi value On decimal) 

\d audible alert 7 

\b backspace 8 

\f form feed 12 

\n new line 10 

\r carriage return 13 

\t horizontal tab 9 

\v vertical tab 11 

\\ \ 
\' 

\d binary value corresponding to octal digit d. 

\dd binary value corresponding to octal digits dd. 

\ddd binary value corresponding to octal digits ddd. 

ConstraintAn these last three cases the binary value 
must fall into the range allowed for characters on 
the target machine. Each "d" must be an Digit as 
defined in the grammar. 

\xd binary value corresponding to hexadecimal digit d. 

\xdd binary value corresponding to hexadecimal digits dd. 

\xddd binary value corresponding to hexadecimal digits ddd. 
Constraint \r\ these last three cases the binary value 
must fall into the range allowed for characters on 
the target machine. Each "d" must be a Higit as 
defined in the grammar. 
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In the forms Xddcl and \xddd, once again the "longest text" 
rule of Section A(7A?//i0/7 applies. For exannple/*\78' is an 
illegal Char: it would be two characters, \7 and 8. 

String. The enclosing quotes for Strings have no meaning 
themselves, but are merely delimiters of the string text. Each 
enclosed character denotes Its corresponding character in the 
target character set, with the exception of \ and ". When \ 
appears, it and the character following it together have the 
meaning as indicated in the above table for Char. 

The value of a String S depends upon its type T; see £^^/7- 
stra/nts above. If T is a pointer type, the value is a pointer to 
an array A of characters such that A[i] is the i^ enclosed 
character, for i i < L, and A[L] is the value of the character 
'\000'. Here L Is the number of characters in S. If T is an 
array type, the value of S is A. 

Discussion 

The Char 'X' does not have the same value as the String 
"X". Confusing these is a common mistake in C and can cause 
disastrous results. For example, if function G expects a 
character string, the invocation "GCx'); " may cause 6 to run 
through arbitrary amounts of memory looking for the 
terminating 'NOOO*. 

\a, \v, and hexadecimal escape sequences are inventions of 
X3Jn notinKR. 

KR and 4.2BSD permit the "default" case of \C, where C is 
not in the table above; in this case \C means the same as C. 

Examples: 

Characters: Strings: 

I A I M A« 

•\" "He said, V'She's dead.V" 

•\t' "THIS IS A STRING." 

*;• "Praise God from whom all blessings flow." 
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4.9 Operators • 

Syntax 

Operator -> AssignOp | OtherGp; 

OtherOp -> •~' | •&' '&• I T M' I '>* • = ' 

I •<• I •«• •»• I ••• '»• I •<' '«• 

I •>• I '+• •+• I •-• •-• I •-• •>• 

I •!• I '»• I •.' I '?• =>'<AS_IS>'; 

# Operators that can be followed by '=' in assignments. 
AssignOp-X''^' | *>' •>' | '<• '<' 

!•+• I •♦♦• I •&' I •*• 

) •=•? =>'<AS_IS>'; 

Semantics 

Operator nneanings are described in Section Expressions. 

Discussion 

KR and 4.2BSD permit the anachronism "x =+ 1" instead of 
the recommended "x += 1". The former can be misinterpreted 
as assigning the value +1 to x rather than incrementing x. 
X3J1 1 forbids the anachronism, as do we. 



4.10 Punctuators ■ 

Syntax 

Punctuator-> '(' | ')' I ';' I '. ' '.• 

I •[• I ']• I •,' I '.' '.' '.• 

I '{' I •}• I •:' =>'<AS_IS>'; 

Semantics 

Punctuators (or "punctuation marks") have no semantics In 
and of themselves. They separate other words In C, and their 
placement Is constrained by the phrase-structure syntax. 
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Discuss/on 

The punctuator . . . was added by X3J1 1 to allow specifical- 
ly designating a function as callable with a varying nunnber of 
argunnents. . . is a High C extension to support ranges in the 
svitch construct. Neither punctuator Is in KR or 4.2BSD. 



4.11 Delifliiters and Eol • 

[uhite space] 

Syntax 

Delimiter -> ( Space: ' '+ | HorizTab: 'ht' 
I FormFeed:'ff I Vert: Tab: 'vf 
)+ ->'<DELETE>'; 

Line_end -> Eol =>'<DELETE>'; 

Note that Delimiters are not Involved in the phrase- struc- 
ture definition of C programs, since Delimiters are words 
nanned <DELETE>. 

Due to the line orientation of the preprocessor, Eol Is not a 
Delimiter as might be expected. 

Semantics 

Delimiters, commonly called "white space", are entirely 
insignificant. Their only purpose is to separate words. Eol 
separates sequences of included or excluded Text and 
terminates Control_lines (see below). 

Discussion 

The addition of the FormFeed character Is an extension over 
KR. In addition, KR dictates that Eol is the new- line charac- 
ter. This is not necessary on systems that support a different 
convention for line termination. 
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4.12 Comments • 

Syntax 

Comment -> V •♦^' Rest =>'<DELETE>'; 

Rest -> Most** •*•+ (V I (Most-V) Rest) ; 
Most -> Any-'**' | Eol; 

Semantics 

Comnnents have no effect on the progrann's nneanlng. 

Discussion 

The grannnnar for Comment is a precise description of 
connments that begin with the two adjacent characters "/»" 
and end with the two adjacent characters "V. "Adjacent" 
implies that an Eol cannot appear between the two characters^ 
even if the Eol is not reaMy a character but a file-system 
end-of-record, for example. 

Comments do not nest. Commenting out code containing 
Comments can be achieved by using the C preprocessor (see 
Section Preprocessor, as follows: 

#if 

. . . commented out code . . . 
#endif 

A good way to write large block comments with standard 
Comments Is exemplified below: 

* This is a 

* block comment 

* whose left edge is 

* lined with *s 

*♦ to make it stand out. 
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-> (\Sharp Skipped_line)»; 
Sharp -> •#•; end Sharp 
-> Skip_suffix? Line_end; 
-> ( Not_special | Slash 

I Comment | DString )*; 

(Any - •/'-'-•)+ 



-> 



-> String_text 



=> •<DELETE>'; 
-> •<DELETE>'; 
=> •<DELETE>*; 



Syntax 

Skipped_lines 
scanner Sharp: 
Skipped_line 
Skip_suffix 

Not_special 

Slash 

DString 

This is the description of lines that are excluded fronn 
compilation. Control_lines are the only lines that are not 
skipped^ and even then only Control_lines not within Comments. 
The notation "\Sharp" means that each Skipped^line must not 
begin with a Sharp ('#'X thereby ensuring that Control.lines 
are not skipped. 

Skipped lines conform to a small amount of lexical syntax: 
Comments and Strings must be well-formed. Comment syntax Is 
included is to permit Control_lines to be part of Comments, i.e. 
to allow Control_lines within excluded Text to be "comment- 
ed out". String syntax is included so that "/*" in a string is 
not misinterpreted as the beginning of a Comment. 



4.14 Control Lines: Preprocessor Commands ■ 

Due to the complexity of the preprocessor syntax/ both its 
syntax and semantics are deferred to the next section. 
Preprocessor. Thus the lexical grammar in this section Is, as 
it stands, incomplete. 
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4.15 Reserved Words • 

Syntax 

end C^lexicon 

reserve *< IDENTIFIER >' 

The following are words appearing in the phrase-structure 
grannmar (discussed in the next section). As discussed in 
Section Notation ^hz\\ word below is therefore not an <IDEN- 
TIFIER> word, but Instead a reserved word. The innplication is 
that the C progrannnner nnay not use these words as user- 
colned < IDENTIFIER >s: 

Int char float double long short unsigned signed 
struct union typedef auto static extern register 
goto return break continue if else for do while 
switch case default entry sizeof void enum pragma 

Discussion 

Sonae implementations also reserve the words asm and 
fortran. signed is not reserved in 4.2BSD or KR, but is in 
X3J1 1 . pragma is reserved only in High C. 
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5 
Preprocessor 



5.1 Introduction 



[conditional conpilation; file inclusion; nacro leplacenent; lexicon; 
phrase-structure; preprocessor connands; lexical analysis; feedback] 

As mentioned In the previous section, the C preprocessor 
does three things: conditional connpilatioa file inclusion, and 
macro replacement. In this section we define what these 
terms mean. 

The preprocessor may be thought of as a level of des- 
cription and program source transformation that lies roughly 
between the lexicon and the phrase structure of C. However, 
this Is not a precise division since the preprocessor commands 
themselves are embedded in C program source text, must 
therefore be lexically described, and hence impact the lexicon 
of C. Furthermore, due to the semantics of file inclusion, 
lexical analysis and preprocessing cannot be separated. This is 
described in greater detail in file inclusion, below. 

Another way of looking at the preprocessor is as a filter 
that takes the word sequence WS generated by lexical analysis 
and produces a new sequence of words subject to C phrase- 
structure analysis. Some of the words in WS are interpreted 
as preprocessor commands, and are processed and discarded by 
the preprocessor; others are replaced by other words; the rest 
of the words are left alone. In a program with no preprocessor 
commands, the preprocessor does nothing to WS, and all of WS 
Is subject to the C language phrase-structure analysis. 

However, again due to the requirement that lexical analysis 
and preprocessing must occur at the same time, the filtering 
cannot be separated into a distinct pass but must occur during 
lexical analysis. (When the preprocessor is Implemented as a 
separate pass, it is at the expense of redundantly doing most 
lexical analysis in both the preprocessor and compiler perse) 
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The preprocessor "filter" is broken up into two pieces: the 
macro replacennent (MR) phase, and the connnnand inter- 
pretation (CI) phase. MR occurs immediately after lexical 
analysis. CI occurs after MR, which means that some of thef 
preprocessor commands may have been subjected to macro 
replacement. Example: 

#def ine RELEASE 2 
#if RELEASE > 1 
. . . some text T 
«endif 

When CI processes the "#if " command, the text "RELEASE" 
has already been replaced with "2", so that CI Includes text T 
(because 2 > 1). 

However, some preprocessor commands must avoid macro 
replacement. For example, "#ifdef RELEASE", which asks if 
RELEASE Is defined, will not work if RELEASE is replaced with 
"2", since CI will instead process "tifdef 2". Therefore CI 
must occasionally Instruct MR to avoid replacement. 

Finally, due to the semantics of file Inclusion, CI occa- 
sionally directs the lexical analysis phase to include text from 
a file. Pictorial ly, the relationship between MR, CI, and other 
phases of a C language translator is as follows: 

Source Text 



tinclude 





LcxiCdi Mnaiysis ^ 




i 












1 


Preprocessor Command Interpretation ' 


i 




Phrase- Structure Analysis 



The arrows leading back from CI to MR and Lexical Analysis 
indicate the occasional "feedback" from CI to the other two 
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phases. This feedback is the single reason that preprocessing 
and lexical analysis cannot be separated into separate passes. 

In this section we first present the portion of the C lexical 
rannnnar that describes the preprocessor connmands and that 
»vas deferred from Section Lexicon.^\\\% connpletes the lexical 
description of C. 

Then, the phrase structure of the preprocessor is presented 
— how the preprocessor interprets the words determined by 
lexical analysis, including the ferreting out of preprocessor 
commands. The semantics of the preprocessor commands are 
described relative to the preprocessor phrase structure. 



5.2 Control Lines r ■ 

Syntax 

Control_line -> Sharp Delimiter? Control; 

Sharp -> •#• ->'<DELETE>'; 

Observe that the Sharp of a Control_line lies In column 
one of an input line due to the placement of Control_line in 
the productions for Text (see the previous section), where it 
appears either: (a) at the beginning of the source input; (b) 
after a Line_end; or (c) after Skipped_lines, which always end 
in a Line end. 



5.3 "Comment" Control Line Lexicon • 

Syntax 

Control -> Line_end; 

If nothing appears after the # and optional trailing 
Delimiter on a control line, the text is all deleted and the line 
is effectively a comment. 
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5.4 Macro Definition Lexicon 



Syntax 

Control -> /Define^word Define Delimiter Macro 
Words Done Line_end 
scanner Define word: 



Define_word 

end Define_word 

Define -> Define word 



-> 'd' 'e' 'f 



Macro -> Id_text \LP 
-> Id_text /LP 
scanner LP; LP -> '(' 



end LP 



i' 'n* 'e'; 

=>'<CQNTROL>'; 

->'<NO_PARMS>* 
=>'<WITH^PARMS>'; 



Macro definition requires special lexical processing that 
complicates the grannmar — yet another place where C pre- 
processor syntax is not we 11 -designed. 

The placement of a left parenthesis as the next character 
following a macro name (ld_text) has different semantics 
from a left parenthesis separated from the macro name by one 
or more characters. The difference is conveyed by the distinct 
word names (<NO__PARMS> versus <WITH_PARMS>) for the Id_text, 
and is further explained below in Section 5.8. 

The /Define_word resolves an ambiguity among Control_ 
lines, since macro definition is lexically a subset of other 
control lines. If define appears immediately after the Sharp 
and optional Delimiter, this rule for Control takes precedence 
over all other alternatives for Control. 
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5.5 Other Control Line Lexicon ■ 

[else in lexical grannars] 

Syntax 

Control -> (Include_text else Other_control) 
Words Done Line_end; 

Done -> =>*<C-EOL>' ; 

Other_control -> Id_text =>'<CGNTROL>'; 

scanner Include_text: 
Include_text -> Include^word Delimiter? Funny_string; 
Include_word -> 'i* 'n' 'c' '1' 'u' 'd' 'e' 

=>*<CONTROL>*; 
Funny__string -> L_angle File^name R__angle; 
L^angle -> "<' =>'<DELETE>'; 

R__angle -> '>' =>'<DELETE>'; 

File_name -> (Any- 'X' -""-'>' I '\' Special)** 

=>'«STRING»'; 
end Include_text 

The grannmar-reserved word else serves to resolve an 
annbiguity, since Inolude_text and Gther_control can generate 
Sonne identical character sequences, else lised here forces the 
Include^text interpretation to prevail where a conflict exists. 
This rule for Control nnay not be used when the nnacro defini- 
tion rule can be used; i.e. the nnacro rule takes precedence. 

All preprocessor connnnands end at line boundaries. The 
word <C-EOL> marks those boundaries and allows the prepro- 
cessor sennantic phase to distinguish preprocessor comnnands 
fronn other C text. Note that Done precedes Line__end every- 
where it appears and therefore always marks a line boundary. 

Include_text describes one of the sloppiest parts of the C 
preprocessor syntax: the form "finclude <string>'' of file 
inclusion. Here a string is delimited by < and > rather than the 
standard double-quotes (**) provided elsewhere in the C lexicon. 
The cost is a duplication of some of the string definition 
syntax. A better language design would have been to use a word 
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other than "#include": "#L_include "string"" for "library 
include", for example. 



5.6 Control Line Phrase Structure 



Now we present the phrase structure of the preprocessor. 
The gramnnar describes connpletely the sequence of words de- 
ternnined by lexical analysis^ but recall that the preprocess- 
ing is interleaved with the lexical analysis, so that the grann- 
nnar cannot be understood to be a description of an already- 
generated sequence of words: the sennantics of. preprocessing 
changes that sequence of words. 

Note that the preprocessor "comnnent" discussed in 
Section 5.3 above need not and is not addressed in the phrase 
structure. 

Some new notation: 'wordname* I'text* in the grammar 
below indicates the word whose name is *wordname' and whose 
text is 'text*. The preprocessor phrase-structure grammar is 
the only grammar that depends upon the text of some words. 

Syntax 

Text -> (Control.text | Word)*; 

From the preprocessor's point of view. Text has little 
structure: it is just a sequence of Words, occasionally inter- 
rupted by preprocessor commands and the text enclosed by 
such commands (Control_text). 
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5.7 File Inclusion ■ 

[include] 

syntax 

[)ontrol_text 

-> •<CONTROL>'! 'include' '«STRING»' '<C-EOL>' 

-> '<CONTROL>'! 'include' •<STRING>' '<C-EOL>' 

-> '<C0NTROL>'!'c_include' '<STRING>' '<C-EOL>'; 

Semantics 

A file inclusion preprocessor comnnand substitutes an 
entire source file F for the comnnand. The substitution must 
occur immediately after processing the command and during 
lexical analysis, so that the the contents of F may also be sub- 
jected to lexical analysis. Thus the concept of preprocessor as 
filter concept Is accurate only if the preprocessing Is thought 
of as proceeding concurrently with the lexical analyzer. 

Due to the semantics of file inclusion this concurrency can 
be avoided only if the preprocessor Is run as a separate pass 
preced/ng\ex\z^\ analysis, in which case the preprocessor must 
nave its own lexical analyzer within It — but this just shows 
again that lexical analysis and preprocessing must happen at 
the same time. 

A substituted source file Is considered to be terminated by 
a Line_end even if it is not. This prevents a word starting at 
the tail end of a substituted source file from being "continu- 
ed" in the file containing the tinclude command. 

The first two tinolude commands differ only in how the 
preprocessor locates the file; this is implementation-defined. 
The last command ("conditional" include) differs from the 
second only in that file inclusion does not occur if the file has 
already been included. 

In all three forms the name of the file searched for is the 
text of the «STRINQ» or <STRING> word. 

Discussion 

The conditional include concept appears only in High C. 
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5.8 Macros ■ 

[nacro paraneters and argunents; nacro body; replacenent text; nacro 
replacenent; tdefine and tundef; paianeteiless and paraneterized 
nacros; benign redefinition] 

C includes the notion of a /77^^/7? facility. A nnacro is an 
identifier M associated with some macro bodym^ possibly 
some macro parameters. 

An occurrence of M causes it and possibly other words 
following It to be replaced by a different sequence of words 
called the replacement /fiY^which is derived from the macro 
body and possibly some supplied macro arguments. This is 
called macro replacement it is more precisely defined later. 

Macro replacement is performed on the word sequence 
produced by lexical analysis before the preprocessor analyzes 
that sequence for preprocessor commands, i.e. before any 
analysis based on the preprocessor phrase-structure grammar 
(PPSG) is performed. The nonterminal Words in the PPSG 
represents Words upon which all applicable macro replacement 
has been performed, with exceptions as noted. The semantics 
of macro replacement is defined formally below. 

Syntax 

Control_text 

-> XCONTROL)* I 'define* 

( Mname:*<NO^PARriS>' Body: Words 

I Mname:'<WITH_PARMS>' 
•(• Parm:'<IDENTIFIER>' list ', ')? *)' Body: Words 

) 
•<C-EOL>* 
-> •<CONTROL>*l'undef Mname: •<IDENTIFIER>' XC-EOL)' 

* 

Constraints 

In the «def ine command, if the Mname is already defined as 
a macro M, its definition must be the same as M, where same 
means the parameter <IDENTIFIER>s and the Body must be 
identical. (This is known as "benign redefinition".) 
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No two Parm: <IDENTIFIER>s in the <WITH_PARMS> form of 
the #def ine may be the same. I.e. have the same text. Stated 
another way, macro parameter names must be distinct from 
each other. 

Semantics 

Both forms of the tdefine preprocessor command define 
an Identifier to be a macro with body Body: Words. No macro 
replacement is performed on the Body of a #def ine command. 

In the first form of tdefine, that with the <NO_PARMS> 
macro name, the macro is called a parameter/essmdizro, and 
subsequent instances of the macro are replaced by the 
Body: Words. Note that <IDENTIFIER> Is a word with text; the 
text Is the macro's name. 

In the second form of define, that with the <WITH_PARMS> 
macro name, the macro has a list of zero or more parameter 
<IDENTIFIER>s, and Is called a parameter/zedmdizvo. 

For macro replacement to occur for a parameterized 
macro M, the occurrence of M must be followed by a left 
parenthesis, a number of arguments that match the number of 
parameters, and a concluding right parenthesis. The structure 
of the arguments Is defined later. Supplying the wrong number 
of arguments is an error. 

The replacement text that replaces M and Its parenthesized 
argument list Is the macro body with any occurrence of a 
parameter <IDENTIFIER> In the body replaced by the corres- 
ponding actual argument from the argument list. 

In all cases, after macro replacement has occurred, the re- 
placement text is reprocessed for any other possible replace- 
ment, with the exception that macro replacement does not 
occur on a macro named M contained directly or Indirectly in 
text resulting from a replacement of M. The exception pre- 
vents an endless loop in macro expansion. Furthermore, macro 
replacement occurs on arguments to a macro M before M 
Itself is subjected to replacement. 
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We more formally specify macro replacement below by 
defining JfCWS), the result of macro replacement on word 
sequence WS with respect to set F of macro names whose 
definitions must temporarily be "forgotten" so that endless 
loops can be avoided. One might read fp as "forget F while 
substituting In WS". f{>(WS) is the result of macro replace- 
ment on the word sequence WS resulting from lexical analysis. 
In the definition || denotes concatenation of word sequences, 
and W is a single word. 

f f(WS) = 

if WS is the empty sequence, 
then WS; 

else if WS is of the form W || WS*, and W is not a 
macro name or W is an element of F, 
then WllfF(WS'); 

else If WS Is of the form W || WS' and W is a 
macro without parameters, 
then fFU{w}(Rep(W))||fF(WS*); 

else if WS is of the form W || '(' || Arguments || ')' 
II WS', and W is a parameterized macro 
with n formal parameters, and there are n 
Arguments (defined below) Ai, A2, ..., An, 

then f F u {u}(Rep(W,Ai',A2'...v An ')) || f f(WS'), 

where Ai' = JfCAi); 

else WS is of the form W || WS' where W is a 
parameterized macro lacking the appopri- 
ate number of parameters, and the result is 
WllfF(WS'). 

Rep(W,Ai,A2,.. A)) is the replacement text for macro W with n 
arguments Ai,A2,..At. derived from W's macro body B by 
replacing each occurrence of the i^ parameter <IDENTIFIER> 
InBwith Ai. 

The Arguments to a parameterized macro are described by 
the following subgrammar: 



V. 11 . 01 . 85 © 1Q84-B5 HetaUare Incorporated 



Preprocessor page 5-11 

Arguments -> '(' W* list ', ' •)'; 
W -> Word -•('-•,•-';' 

-> •(• (W I ', ')- •)'; 

After a tundef command, the named macro Mname Is no 
longer a macro (its definition is "forgotten"). If Mname Is not 
a macro, the #undef command has no effect. 

Discussion 

Essentially an argument to a parameterized macro may not 
contain ", " except within properly balanced parentheses. But 
note that an argument can be an empty sequence of words, so 
that in 

#def ine call(f, arg) f (arg) 

call C 3) 

"callC3)" is replaced by "(3)". 

In addition, since an occurrence of a parameterized macro 
Is not replaced unless the appropriate number of arguments is 
present, one can ensure that a library function being invoked Is 
not a macro by parenthesizing the functions 

iinclude -stdio. h" 

/* If getc is a macro, it is replaced here: V 

c = getc(F); 

/* But here the macro is not replaced; V 
/* instead, function getc is called: V 

c = (getc)(F); 

Benign redefinition has been adopted by X3J1 1 as a way to 
permit the inclusion of a commonly used macro name, such as 
"NULL" (typically defined as "(void ♦*)0"), In each library 
header file that requires it. 

Bug. Our definition of macro replacement avoids some of 
^the absurdities and possible abuses of common C macro pre- 
processors. In at least two C compilers we know of, a macro 
invocation can be constructed from text some of which was 
obtained from a macro replacement and the rest elsewhere. 



V. 11. 01 . B5 © 1984-85 HetaWare Incorporated 



Preprocessor page 5-12 

For example^ the following is acceptable to these two compil- 
ers, producing "int i » (3)*(3); " fronn the expansion: 

♦define start sqr( 
♦define sqr(x) ((x)**(x)) 

int i = start 3 ); 

Our definition does not pernnit a nnacro body to contain 
unnnatched parentheses, if these parentheses follow a nnacro 
name whose replacement is intended. The formal derivation is: 

f {} ("int i = start 3); ", ) 
= "int i = " II f<start}(Rep("start")) || J<}("3); ") 

- "int i . " II /{stamCsqr (") || "3); " 
= "int i = 'Sqr(3);'' 

The result draws a syntax error from a language processor 
unless Sqr is a defined function. 

But it is still possible to construct a macro invocation 
from pieces when the pieces are joined within the replacement 
text of a single macro: 

tdef ine x g(h 
♦define h(f) f (3)) 
♦define g(i) i+1 
h(x); 

foChCx);") 

= f{h}(Rep(hJ<>("x"))) IU<}(";") 

- f<h}(Rep(h,f<x)(Rep("x")))) II";" 
= /{hKRepMixK-'gCh"))) II";" 
= f{h}(Rep(h/'g(h''))) || ";" 
= f{h>(f{h>C'g(h(3))")) II";" 
= f{h>(f{h,fl}(Rep(gJ{h}rh(3)"))) II ";" 
= J<h>(J<h.o}(Rep(g/'h(3)"))) || ";" 
= f{h}(f<h.g}rh(3)*1")) II";" 
= f<h)("h(3)^1") II";" 
= "h(3)+1" 11";" 
= "h(3)+1;" 
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Here an Invocation of h was constructed fronn the argu- 
ment X, expanded to g(h, and the matching parentheses in the 
body of h. The best one can say about this usage Is that it is 
good for boundary examples in documents such as this one. 

The C compilers mentioned previously generate "3(3))+1" 
from "hM", mainly because the way they avoid an endless 
loop is by placing an upper limit on a macro expansion buffer, 
rather than actually detecting the loop. 



5.9 Predefined Macros • 

LLINE__, __FILE_] 

__LINE__ and __FILE__ are predefined parameter less 
macros. The first expands to a decimal digit string whose 
value is the line number of the source file containing the 
occurrence of __LINE__. The second expands to a quoted 
string literal, the name of the file containing the occurrence 
of _ _FILE_ _. These macros are most useful for debugging: 

printf ("Now at line %d in file 'iJsNn'V 
__I-INE_^ __FILE ); 



5.10 Conditional Inclusion 



[•if, #ifdef, tifndef, telif, felse, tendif; defined; constant 
expression; nacro replacenent; enabling condition; Signed- Long- 1 nt] 

Syrftax- 

Control_text 

-> ( '<C0NTR0L>'!'if' E •<C-EOL>* If : Words 

I '<CONTROL>'!'ifdef '< IDENTIFIER >' '<C-EOL>' Words 
I '<CONTROL>'!'ifndef' •<IDENTIFIER>' 'KC-EOL)' Words 
) 

('<CONTROL>'!'elif' E '<C-EOL>' Elif: Words)- 

('<CONTROL>'!'else' XC-EOL)* Else: Words)? 

'<CONTROL>' ! 'endif • XC-EOL)* 

E -> ... see the next paragraph. 
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The E nonterminal generates the sanne language as E2 in the 
C phrase-structure grannmar (see Section Expression^, except 
that the only allowable occurrences of <IDENTIFIER>s in E are 
as follows: 

( i ) • <IDENTIFIER> • ! ' defined * Mname: ' <IDENTIFIER> ' 

(ii) ^IDENTIFIER)'! 'defined* '(' Mname: '<IDENTIFIER>' ')' 

(iii) Mname: •<IDENTIFIER>' 

Constraints 

E nnust generate a constant expression (see Section 
Expressions/Constant Expression^ of an integral type with no 
occurrences of the sizeof operator^ enunneration constants^ 
or type casts. 

Semantics 

Macro replacement does not occur for the single word 
appearing after '<IDENTIFIER>' {'defined ', in case (i) or (ii), 
or for the single word appearing after the '(' in case (ii). In 
addition, no replacement occurs for the <IDENTIFIER> follow- 
ing #if def or #if ndef . 

Conditional inclusion. «if -#if def -«if ndef, telif, and 
telse provide a conditional text inclusion facility based upon 
the value of an expression E or the existence of a macro defini- 
tion. Only one of the sequences of Words in a #ifxxx-#endif 
command is included; all others are excluded. 

The included sequence is the first sequence of Words such 
that the enabling condition of the preprocessor command 
containing the Words is True. The enabling condition for the 
#if and #elif commands is that E evaluates to a non-zero 
integer value. The enabling condition for the tifdef command 
is that the <IDENTIFIER> ]s defined as a macro; for the #if - 
ndef it is the reverse. The enabling condition for the #else 
command is True, i.e. if no other enabling condition holds, the 
Words associated with the #else command are included. 

Macro replacement does not occur on excluded text. 
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Evaluation of E. Each conditional inclusion expression E is 
evaluated using the host envlronnnent's Signed-Long-Int arith- 
metic, as If all operands had type Signed-Long-Int rather than 
the type normally dictated by the Constraints of C express- 
ions; see Section Expressions. 

In all cases (i)-(lM) for < IDENTIFIER >s, the expression evalu- 
ates to zero or one according to whether Mname is currently 
#define-d or not. Note that In the third case of a single 
<IDENTIFIER>, the value one Is rarely obtained^ since the only 
way the <IDENTIFIER> could be a macro name is if the macro 
were recursively defined so that replacement stopped, leaving 
the macro name. Examples: 

fdef ine x x 

#if X /* Same as "if 1". V 

. . . this text is included . . . 
fendif 

fundef X 

#if X /*• Same as "if 0". V 

. . . this text is excluded . . . 
fendif 

Obsolescence, tifdef and fifndef provide nothing that 
#if -felif -telse-fendif do not already provide, and the for- 
mer's use is discouraged In favor of the latter's. fifdef and 
#ifndef can be avoided as follows: 



This 


can be replaced m'th 


#if def X 


#if defined(x) 


#endif 


fendif 


#if ndef x 


fif !defined(x) 



fendif fendif 

Some compilers permit arbitrary text on a line following 
fendif and f else. This supports a common UNIX practice ex- 
emplified by "fifdef X ... fendif X". X3J11 recently decided 
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to permit the text after tendif and #else to be implemen- 
tation-defined. 



5.11 Preprocessor Words ■ 

Syntax 

Words -> Word*; 

Word -> Any - ^CONTROL)' - '<C-EOL>' 

# Any word produced by lexical analysis 

# other than the two explicitly excepted. 

Semantics 

Macro replacement occurs on all Words, with the excep- 
tions as noted above: for the word following '<IDENTIFIER>' I 
'defined' and the word following •<IDENTIFIER>' ! 'defined' 
'('in the case of the conditional Inclusion expression E^ for 
excluded Words, and for Words that are a macro Body. 
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6 
Declarations 



6.1 External Declarations ■ 

[Unspecified declaration; Functionjdef inition: In.fNctiMjifiiitiMR; 
Specified.declaration; pragnas froit Ada; toggles; block; fpragm] 

Syntax 

parser C_phrase_structure: 

Cj)hrase_structure 

-> External_declaration* 

• 

# Declarations. # 

External_declar ation 

-> Unspecifled_declaration: 

( Functionjdef inition 

I Non_function_def initions '; ' 

) 
-> Specif ied.declaration f Vith specifiers. 
-> Pragma call 

-> •; • # Syntactic oddity of KR. 

» 

Praonia call 

-> 'pragma* Name ('(• (E list *, •)? •)•)? ';• 
» 

A C program consists of a sequence of declarations and 
pragnr^as. Sonne declarations are also definitions. 

Constraints 

There is a block E that is the text of the entire progrann. 
Any block Introduced by any definition — an Unspecified^ 
definition or a Specif ied_declaration ~ is a part of E. 

Specifiers are assumed in an Unspecified_declaration 
according to rules set forth in the next Subsection. 
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Semantics None. 

Discussion 

Pragmas are found in no other definition of C. The syntax 
is taken fronn Ada. The intent is to allow the programmer to 
give directives to a C language processor. For example^ ait 
MetaWare C compilers support pragmas named Set, Reset, 
and Pop, which take a single identifier as the name of a toggie 
stac/c and either push True (set), push False (Reset), or pop the 
stack. The value on the top of the toggle stack affects 
language translation in some way, depending upon the nature of 
the toggle. 

Beyond this we say no more about pragmas, leaving their 
further definition to another document more specific to 
MetaWare High C and High C implementations. A related 
notion is the newly- introduced "tpragM" preprocessor 
command found in the X3J1 1 document* we have not included 
ipragaa as part of our definition. 

Pragmas are also permitted in statements; see Section 
Statements. 



6.2 Specified Declarations • 

[Specifiers; FwctitiJtfiiitiN; iHLfMctiNjifiiitiMs; S^tdfiKJiclintiit; 
!xtern«ljlecl«ration; autoMtic storage class] 

Syntax 

Specif ied_declaration 

-> Specifiers •; • 

-> Specifiers Function_definition 

-> Specifiers Non_function_definitions '; ' 

Constraints 

The Specifiers of a Specif ied_declaration that is syntac- 
tically immediately derived from an External__declaration 
may not denote the storage class automatic; see 6.3 below for 
how Specifiers denote a storage class. 
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Semantics None. 

Discussion 

Declarations are broken up into (1) the definition of func- 
tions (Function^definition) and (2) declarations that are not 
function definitions (Non_function_def initions), but that may 
be function declarations or definifions of names of non- func- 
tion types. 

Only one function can be declared In a Function_defini- 
tion, but many non- functions may be declared in Non_func- 
tlon^definitions. 

The alternative "Specifiers ';'*' Is permitted to allow 
the declaration of a type T without also declaring a name for 
type T. For example^ "struct s {int x; }; typedef int t; " 
declares a tag s referring to the Struct{...} type and a typedQf 
name t standing for the Signed- Int type. 



6.3 Types and Specif iers 

[StiraiijcltstK Mta, utara, rtfittfr, tf nii f, ttatic; tijtctlwt 
start, w nin ti, ltM« tiftH; dMr, itt, flttt, itillt, ftii; <TTFnEFJMIIE>; 
S^^trt; iMtjiytafiin; OMftM^.ttatiMiit; lit.fiactiM itfiiitiit; 
FwctiMjtfiutiit; liSHcifiitf.iiclirttiM; S^dfiti.itclirttlM; static-iiftrt, 
mtlc-npirt, sutlc-privttt; Mtuntic, tf^rttf; t|^ if dMr; uitlMttic tipcsj 

Syntax 

Specifiers 

-> Type_or_stprage_olasses 

Type_or_storage_classes 

-> Storage_class Type_or storage.classes? 

-> Typedef _reference:*<TYPEDEF_NAME>' Storage^class? 

-> Type ASCs 

-> Adjective ASCs (Type ASCs)? 

ASCs -> (Adjective | Storage_class)* 

» 

Storage_class 

-> 'auto* I 'extern' I 'register' I 'typedef | 'static' 
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Adjective 

-> ' short ' I • unsigned ' | * long * | • signed • 

» 

Type__specifiers 

-> Typedef^reference: '<TYPEDEF_NAME>' 

-> Adjective* Type Adjective* 

-> Adjective* 

» 

Type 

-> <*char'|*infrfloaf|*clouble'Mvoid*> 

-> Tagged_type; 

Specifiers are complicated by the syntactic rules for the 
interpretation of <IDENTIFIER>s as <TYPEDEF_NAr€>s. The conn- 
plexity bears sonne detailed explanation here. 

Specifiers are essentially a sequence of Storage_classes^ 
Types, Adjectives, and <TYPEDEF_NAME>s, where 

(a) there may be at most one Storage.class, a constraint that 
v^ould be clumsily imposed by the grammar; 

(b) there may be at most one Type or <TYPEDEFjlAr€>: imposed 
by the grammar, and necessary to properly interpret 
<IDENTIFIER>s as <TYPEDEF_NAME>s where appropriate — 
this is the reason for the grammar's complexity; 

(c) a <TYPEDEF_NAME> may not be combined with an Adjective; 

(d) only certain combinations of Adjectives are permitted, a 
constraint that would be clumsily imposed grammatically. 

A <TYPEDEF_NAnE> is an <IDENTIFIER> that is declared of 
mode typedef in the ordinary name space. Effectively, any 
time such an <IDENTIFIER> word appears, it becomes a <TYPE- 
DEFJW€> word. The grammar permits at most one occur- 
rence of a <TYPEDEF_NAME> in Specifiers or Type_specif iers, 
and does not allow if to be combined with a Type. Essentially, 
the <TYPEDEF_NAME> specifies the type (see Constra/nts\ie\o\N\ 
and therefore the combination with another Type, <TYPEDEF_ 
NAME>, or Adjective (type modifier) is meaningless. The Ice is 
notX\\\^ here. 
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Examples: 

typedef int T; 

void F() { 

Tx; /»xisof typeT»Slgned-Int. V 

short T x; /*• Illegal: adjective not allowed. V 
TTx; /* Illegal: two <TYPEDEF.NAHE>s. */ 

register T; /* Illegal: declared name missing. V 
int T; /* A valid re-declaration of T. */ 

} 

The nonterminal Type.specifiers Is the subset of Speci- 
fiers that forbids Storage_classes, and is used elsewhere in 
the grannmar. 

Constraints 

Specifiers and Type.speoif iers denote a type and a stor- 
age class that become associated v/ith the name declared with 
the Specifiers. How to determine that type and storage class 
is discussed next. 

Specification of the storage class. In Specifiers there 
may be at most one Storage.class stated. If the Storage^ 
class is omitted, a storage class is implied based upon where 
the specified declaration appears, as follov/s: 

(a) In an Unspecif ied.declaration, a Function^def inition has 
storage class static-export; a Non_f unction_def inition of 
mode fen has storage class static- import; any other 
Non_f unction^def inition has storage class static- export. 

(b) In a Speoif ied.deolaration that is a part of an External^ 
declaration, the rules in (a) above apply. 

(c) In a Specif ied_declaration that is a part of a Compound, 
statement, a Funotion_definition has storage class auto- 
matic; a Non.f unction_def inition of mode fen has storage 
class static- import* any other Non_function_definition 
has storage class automatic. 
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Examples: 

/* Illustrations of case (a): «/ 

x; 1^ Unspecifiedjleclar«tion:Non_functionjlefinition 

>> static-export storage class. V 

y(); /* Unspccified^dcclaration: Mon_f unction jtefinition 

«> static-inport (due to node fen). V 

f(){ /* Unspecifiedjleclaration:Functiofulefinition 

s> static-export storage class. */ 

/* Illustrations of case (c): V 

void g(){~} /* Specified.declaration that is part of a 

Conpoundjstatenent «> autoMtic. But this 
particular case is ruled out elseiihere — 
nested functions are illegal. ^/ 

int h(); /« Specif ied.declaration that is part of a 

Coflpound.statenent *> static-inport. */ 

int i; /* Specif ied.declaration that is part of a 

Cofipound.statemnt »> autonatic. V 

} 

/* Illustration of case (b): */ 

int z; /* Specifiedjdeclaration that is a part of an 

Extemaljleclaration >> static-export. V 
End of Examples. 

if the Storage.class is stated: 

Storag e class denotes storage class 

extern static- import 

static static- private 

auto or register automatic 

typedef typedef 

Note. The static-export storage class cannoth^ explicitly 
written, but is the default when none is specified. 

The Storage__clas8 auto is allowed only in a declaration 
within a function; register is allowed in the same cir- 
cumstances and additionally as the storage class of function 
Parameters. 

Specification of the type. In Specifiers and Type_speci- 
fiers, the grammar permits only zero or one Types or <TYPE- 
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DEF_NAME>s. Any number of Adjectives Is permitted by the 
grammar^ but only certain combinations are legal. In any 
particular combination the Adjective(s) and/or Type may be 
presented in any textual order^ but no Adjective may be 
repeated. No Adjective may appear with a <TYPEDEF_NAr€>. 

If a <TYPEDEF_NAME> is used. It It guaranteed to be declar- 
ed of mode typedef in the ordinary name space of a type T. 
The type denoted by the Typedef_reference is T and is the 
specified type. 

If a <TYPEDEF_NMC> is not used. The next table indicates 
the only allov/able combinations of Adjectives v\/lth int and 
char, and the correspondingly denoted type. The first three 
rovTS may be optionally combined with the Type int. 

Table Adjectives Combined with int and char. 

signed or nothing unsigned 

short SIgned-Short-Int Unsigned- Short- Int Iwith 

long Signed- Long- Int Unsigned-Long- Int lomithout 

(nothing) Signed- Int Unsigned- Int jthe Type int. 

char Signed-Char^ Unsigned-Char 



denoted type 
^Exception: whether char standing alone denotes 
Unsigned- or Signed-Char is Implementation- defined. 

Therefore, if Specifiers contains neither a Type nor an 
Adjective, the "(nothing)- nothing" intersection in the table 
above applies and the denoted type is Signed- Int. 

The Types float, double, and void standing alone denote 
the types Float Double, and Void, double may be combined 
with long to denote the type Long- Double. No other Adjec- 
tive may be combined with double, and float and void may 
not be combined.wlth Adjectives at all. 

For example, "unsigned int short" and "int short 
unsigned" are both allowed and denote the type Unsigned- 
Short- Int. but "int short unsigned short" Is not allowed. 
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since short occurs twice. 

Tagged_types are covered in the next Subsection. 

Examples: /* storage class. Type: *♦/ 

x; /* Static-export Signed-Int */ 

f(); /«• Static-inport (?)-> Signed- Int V 
char y, z; /• static-export Signed- or Unsigned-Char V 

static q, r; /* Static-private Signed- Int «•/ 

mainO { /* static-export () -> Signed-Int */ 

unsigned x. y; /^ Autonatic Unsigned-Int */ 

auto short z, •; /* Autonatic Signed-Short-Int */ 

double extern long 1; 

/« Static-iRport Long-double V 

Semantics 

The meaning of the type specifications and storage classes 
is discussed in the Section Concepts. 

Discussion 

' The reason that the type T denoted by char standing alone 
is innplementation-defined as either Unsigned-Char or 
Signed-Char is due to potential ineff iciences in a computer 
architecture. For example, on the IBM 370 loading an 
Unsigned-Char is much more efficient than loading a 
Signed-Char, so T " Unsigned-Char is preferable. On an 
8Q88, widening an Unsigned- Char to a Signed-Int costs a 
two-byte instruction, whereas widening a Signed-Char to a 
Signed-Int costs only a single byte. 

" Although a Function.def inition of storage class automatic 
is not ruled out by the constraints in this subsection, they 
are in Subsection 6.5. 

" Formally, the Storage.classes auto and register have the 
same semantics: specification of the automatic storage 
class. Generally the Storage_olass register is understood 
by a language processor to place the declared object's value 
in a register; however no semantic ciiange to the program 
must occur through this placement. 
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Example: Some implementations, e.g. Microsoft C 3.00 
on the 8086 under MS-DOS, do not truncate unsigned char- 
acter values when the character is held in a register, so 
that in "register char c « 255; if (++0 =» 256) f ();" f 
may well be called on an 8-bit-byte machine. The value of 
c after the increment should instead be zero. 

■ The only combination of the Types and Adjectives allowed 
here and in KR are "short int", "long int", and "un- 
signed int". It is not clear from KR whether the order 
matters. KR also permits "long float" to stand for 
"double"; High C, like X3J11, does not. High C, like 
X3J11^ uses "long double" to denote type Long-Double, a 
type not In KR. 

• 4.2BSD permits Adjectives to appear with <TYPEDEF_ 
NAME>8. The result Is somewhat as if <TYPEDEF_NAME>s were 
macros instead of names associated with a distinct type. 
Example: "typedef int T; unsigned T x; T y; " Is per- 
mitted. 

This has the perhaps unusual effect that x and y are not^\ 
the same type; x is of type Unsigned- Int and y of type 
Signed- Int. The Adjective overrides the type associated 
with T, changing the type from Signed- Int to Unsigned- Int. 

Note the distinction: "int" standing alone denotes the 
signed Integer type, not an "Incomplete" Integer type; 
specific syntactic combinations to denote various integer 
types are listed above. Both KR and X3J11 concur with 
this manual In insisting that a typedef name denote a 
single, unmodif iable type. 

■ Many C Implementations are two-faced about the use of 
the Storage.class extern. For a function declaration that 
is not a definition, i.e. the body is not being supplied, 
extern always means the function is declared elsewhere, 
but extern on a function definition denotes storage class 
static-export. 
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High C reserves extern for static- import only^ and for- 
mally forbids it on definitions. In a concession to existing 
(poor) practice, MetaWare High C compilers warn when it 
appears on a function definition. Its presence is unneces- 
sary since the absence of any Storage.olass for a function 
definition Implies storage class static-export. 



6.4 Tagged Types 



[«UKt« Miw, mm: inciiplitt sunctiirt ir MdM tin; tai imi sftct; stracturt 
IT itiM anltrs; feit fiiM; ■■■■iTitltt littrals mi tfpt; iMitr ilipMnt] 

syntax 

Tagged_type 

-> Complete_definition: 'struct* Tag? '{• hember.list '}* 
-> Complete__definition: 'union* Tag? *{* Member^list •}* 
-> Use_or_incomplete_deflnition: C struct* I 'union*) Tag 
-> Cofflplete.definition: *6num* Tag? '{' Literal^list *}* 
-> Reference: *enum* Tag 

Literal list 

-> (Name (*-* ConstantrE)?) list ', * '. '? 

Tag 

-> Tag: Name 

Member^list 

-> '{• Also_is_a_list: Members list *;* ';'? *}* 

* 

Members 

-> Type.specifiers (Structure_member list ', *)? 

* 

Structure__member 

-> Declarator 

-> Field member: Declarator? *:* Bits: Constant: E 
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Constraints 

Structures and Unions. If the Tag (Name) is given in a 
Coi!iplete_struct_definition: 

(a) If the Tag Is declared of nnode struct-tag and incomplete 
type Struct{?} In the tag name space, and the origin of the 
latter declaration Is the same as that of the Complete. 
struct_definition, then the Memberjist specification 
completes the original definition of the Incomplete 
struct. From this point through the rest of the origin of 
the Tag's declaration, the Incomplete struct has type 
Struct{M}. where M Is the Member.list. This does not 
create a new type but merely completes an old one. The 
type denoted by the Complete_struct_definition Is this 
completed type. 

Note that the requirements of "same origin" prohibit the 
example cited In Section Introduction, a particular sore 
spot for most compilers and C language definitions. 

(b) Otherwise, the occurrence of the Tag Is Its def Inlng-point 
within the tag name space of mode struct-tag; it has new 
type T » Struct{?} from its def ining-point to the closing } 
of the definition, and then has type Struct{M} where M is 
the Memberjist; the type denoted by the Complete_struct_ 
definition is this new type. 

Furthermore. T may not be completed within the defini- 
tion. This unusual two-stage type association prevents 
Illegal declarations such as "struct S{struct S x;}". but 
permits such declarations as "struct S{struct S *^;}": 
pointers to incomplete types are permitted. 

If no Tag is given in a Complete_struct_definition. the 
definition denotes a new type Struct{M}. 

Similar constraints apply for Complete_union_definition: 
replace struct by union and Complete_struct_definition by 
Complete_union_dGf inition in the preceding three paragraphs. 
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Example: 

struct s; /* A: Declaration of an incomplete type. */ 

mainO { 

struct s *y; /* Reference to declaration A. */ 

struct s {int z;}; /* B: Duplicate declar'n of s. */ 
} 

struct s {int z; }; /* C: completes declaration A. V 

Declaration B is not a completer of A since B and A have dif- 
ferent origins. Therefore the occurrence of s in B is a def in- 
ing-point so that the scopes of A and B overlap, producing 
an Illegal duplicate declaration. On the other hand, the 
origin of A and C is the same, so that C completes A. 

No member in a Memberjist may be of a functionality type 
or of an incomplete type (this prohibits the declaration of x in 
"struct S{Sx;}''.) 

In a Use_or_incomplete_definition, If the Tag following 
struct is declared of mode struct-tag and incomplete type 
Struct{?} or the Tag following union is declared of mode 
union-tag and type Union{?}, the type denoted by the 
Incomplete_definition_or_use is this type. Otherwise, the 
occurrence of the Tag is its def ining-point of mode struct-tag 
and new type Struct {?} (or of mode union- tag and new type 
Union {?}). 

The type denoted by the Use_cr Jncomplete_def inition is 
this type. (This means that in "struct S {int X;}; void F() 
{union S; ... }", the second occurrence of S is an incomplete 
definition, not a reference to the first S.) 

The declaration of an object of type Struct{?} or Union{?} 
whose storage class Is not static- import is illegal; the Struct 
or Union type must first be completed. 

The E appearing in a Field_member must be a constant 
integral expression. If the value of E is zero, the Declarator 
may not be present. The Declarator must be of type Unsigned- 
Int or Signed- Int. 
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Enumerations. Each of the Constants in a an Enum^def ini- 
tion's Literal Jist must be a constant expression of an 
integral type. 

The type T denoted by an Enum_def inition is one of Signed- 
Char, Unsigned-Char, Signed-Short-Int, Unsigned-Short- Int 
Signed-Int, or Signed- Long- Int. 

An implementation may choose any of these types for T 
provided that: (a) the unsigned types can be used only If their 
size is less than that of Signed- Int, so T widens to Signed- Int in 
an expression; (b) T contains the set of values specified in the 
Literal.list, except that a value not contained in Signed- 
Long-lnt is converted as if by type casting to Signed- long- Int. 
See Semant/csbeloM for the specification of the values. 

Generally an implementation chooses the type T having the 
smallest size satisfying the constraints, and chooses the 
signedness depending upon the efficiency of the architectures- 
see the D/scuss/on \i\ Subsection Types and Sped fiers ^hQ^e 
for architectural examples. 

If the Tag is provided, its occurrence is its defining-point 
within the Tag name space of mode enum-tag and the type T 
as specified in the previous paragraph. The occurrence of the 
Names in the Literal Jist are their def ining-points within the 
ordinary name space with mode value and type T. 

In an EnunLreference, the Tag must be declared in the tag 
name space of mode enum-tag and of some type T. The type 
denoted by the Enum_ref erence is T. 

Semantics 

Structures and Unions. A value of type StructfM} or 
Union[M} where M is a Member^list consists of a sequence of 
optionally named objects called members. The members and 
any names are defined by the Structure jnember syntactic 
category. 

The members may be either Declarators or f/e/ds, which 
are sequences of bits. The number of bits in a field is specified 

V. 11. 01. 85 @ 1984-85 ffetaUare Incorporated 



Declarations page 6-14 

by the constant expression E following the ': *. A field F that 
JmnDedlately follows another field F' may be placed adjacent 
to F' in the same storage unit, if possible. 

We deliberately leave unspecified whether adjacent means 
that the least-significant bit of F is adjacent to the most- 
significant bit of F*, or the least-significant bit of F* is 
adjacent to the most-significant bit of F^ but we require that 
adjacent always mean the same thing in a particular imple- 
mentation. 

Adjacency depends upon the the order of allocation of fields 
within a storage unit (left-to-right or right- to- left), which is 
implementation-defined. An implementation may refuse to 
allow a field to straddle an implementation-defined storage 
unit boundary B. 

The width of a field may not exceed the size (in bits) of an 
object of type Unsigned- Int. 

A field of zero bits prevents any further fields from being 
packed into the unit of storage in which the previous field was 
placed, and may additionally cause the next field to be allo- 
cated on the storage unit boundary B mentioned above. 

An unnamed Field_member (the Declarator is omitted) is 
used to conform to layouts imposed externally. 

Within an object of a Struct type, the non-field members 
and the storage in which fields reside have addresses that 
increase as their declarations are read from left to right. 
Each non-field member of a structure may be aligned as 
appropriate to its type; there may therefore be unnamed gaps 
within a structure. 

However, the address A of a structure must be the same as 
the address of Its first member M, If M Is not a field; other- 
wise A must be the address of the storage unit In which M Is 
stored. Thus, there Is no "gap" at the beginning of a structure. 

Within an object O of a union type, the non-field members 
and the words in which fields reside have the same address. 
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which is the same as the address of O. Thus^ there is no "gap" 
at the beginning of a Union. 

Enumerations. When used in an expression^ the successive 
Names in a Literal_list evaluate to 0^ 1, 2, ..^ etc., except 
that a Name with an associated Constant expression E "resets" 
this sequence to the value of E. The values of enumeration 
literals need not be unique. 

For example, "enun {red, orange, blue « 0, green};" is 
permitted: red and blue evaluate to zero and orange and green 
to one. In this example the type denoted is Signed-Char. 

Discussion 

4.2BSD and KR prohibit structures and unions from having 
members of a functionality type. X3J11 is silent on the 
subject. 

4.2BSD permits a structure or union type T in a nested 
block to complete a corresponding structure or union type T' in 
an outer block, with confusing results. In the nested block T 
/nay be used appropriately; in the outer block, T* is incomplete 
and may not be completed. The compiler gives confusing 
messages when the use or completion of T* is attempted in the 
outer block. 

4.2BSD warns when enumeration values and values of other 
types are mixed in expressions. The proposed standard and this 
document say that enumeration values are not of a separate 
type, but are of one of the basic integral types. 

4.2BSD does /3^^^permit redefinition of typedef names, 
such as "Int x; ", where x is a typedef name. This appears to 
be a bug, since an example specifically documented in the KR 
book as correct is disallowed by 4.2BSD. 

The address operator & may not be applied to a field 
member, because most computer architectures do not support 
addressing at the bit level. This restriction is imposed through 
field having the mode field; see the discussion of & in Section 
Express/ons/Po/nter Reference. 
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6.5 Declarators 



[NriMUrs; fUMmtn mms mi tinMs; Mttractj^Mittrs; lbsuact_4tdiratir; 
SHcifitrs; tto tyn •f • itdaratir ar abstract tedaratar; faactiaaalitjp tjfHS mi 
pratatyH faactiaaalitias; iacaaplata tjvts; rtfitttr paraaattrs; paiitar mtt arr^f 
tfpts; typt iaias is paraaatan] 

Syntax 

Declarator 
->•*•• Declarator 
-> Declarator' 

Declarator' 

-> Declarator' '[' Array specification ']' 

-> '(• Declarator ')' 

-> Function__speoification: 

Declarator' '(' Parameters ')' 
-> Declared: Name 

Array_specification 
-> Constant: E? 

Parameters 

-> Parameter_names_only: 

Parameter_name list \ ' Morejparms? 
-> Abstract j)araiiieters 

Abstract_parameters 

-> (SD list ', ' horej;)arms?)? 

SD -> Specifiers (Abstract.declarator I Declarator2)? 

flore_parms -> '. ' '...'?; 

Parameter.name -> •<IDENTIFIER>' 

* 

Abstract_declarator 

-> '**' Abstract_declarator? 

-> Abstract'declarator' 
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Abstract_declarator ' 

-> Abstract^declarator*? '[* Array.specification ']' 
-> Abstract declarator'? '(' Abstract j)aran»eters ')' 
-> •(• Abstract_declarator *)• 

« Declarator2(') is needed to avoid an ambiguity. 

Declarator2 

-> •*• Declarator2 

-> Declarator2* 

» 

Declarator2' 

-> Deolarator2* '[• Array^specification •]' 

-> •(• Declarator2 •)• 

-> Function_specification: 

Declarator2* '(• Parameters •)' 
-> Declared^name: ' <IDENTIFIER> ' 

The nonternninals Declarator2 and Declarator2* are needed 
to avoid a syntactic ambiguity by forbidding the nanne of a 
function's parameter to be a name previously declared of mode 
typedef; see Type Names as Parameters in D/scuss/onhe\€eH. 

Constraints 

Every Declarator declares a single Declared_name N. The 
occurrence of N in the Declarator is its defining point of a 
particular mode M and of a particular type T in one of two 
name spaces. If the Declarator is a Structurejnember^ the 
name space is that for the structure or union type having that 
Structurejnember. Otherwise^ it is the ordinary name space. 

The occurrence of any Declarator is associated with a 
storage class S that Is specified in the Type^specifiers or 
Specifiers preceding the Declarator, or is implied when there 
are no Type_specifiers or Specifiers; see Subsection Types 
andSjpecifiers above. 

Likewise, the occurrence of any Declarator is associated 
with a type T' that is specified in the aforementioned Type_ 
specifiers or Specifiers, or is implied when they are lacking. 
From this type T* and the structure of the Declarator, the 
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final type T of the declared name can be deternnlned. We also 
say that the Declarator is of that type. T Is r}pe(V,D\ 
where Type is defined recursively as follows: 

Table Deolarator Type Determination. 

ryp^J^D) * /fO /s of the form then 

D' [ ] 7>7y^[?]:LD*) 

D* [E] 7>7W<[V]:LD*) 

where E must be a Constant expression of an 
Integral type whose value is V 
(0') 7>;w(LD') 

D* Parameters 7)^F,D') 

where the determination of the functional- 
ity type F is deferred to later discussion 
under the heading Function Parameters 
Name T 

Examples: 

int»(*x)[3LK(int))[]; 

x's type is determined as follows: 

7>jtw(Signed- Int *(*x) [3]) 
» 7)i^«Signed- Int (*x) [3]) 
« 7>^^3]:»Signed-lnt (*x)) 
= 7>jBc([3]:«Signed- Int *x) 
=» 7^i<»[3]:-Signed- Int x) 

- -[3]:-Slgned-lnt 

i.e. X is a pointer to an array of pointers to Signed- Ints. fs 
type is determined as follows: 

Typi,% gned-Int (*f (int))[]) 

- 7>7?41:Signed-lnt K(int))) 
= 7)^4j:Signed- Int *f (int)) 

= 7>7?£("[]:Slgned- Int f (int)) 

- 7>77^(Signed-lnt)n->**[]:Signed-lnt f) 
= (Signed- lnt)p->«[J:Signed- Int 
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i.e. f is a function (with prototype functionality) taking a 
Signed- Int; it returns a pointer to an array of Signed- Ints. 

Abstract^declarator provides a way of specifying a type 
without declaring a name of that type. Like Declarator, 
Abstract.declarator appears in a context that associates a 
type T* with It; in the rule for Abstractjarameters, the type 
comes from the preceding Specifiers, and in the rule for 
Cast.type (see Section Express/ons/Cast Types and Abstract 
Declarator^, from a preceding Type_specif iers. 

The type T denoted by an Abstract_deolarator A is Type 
(T*,AX defined recursively as follows: 

Table Abstract declarator Type Determination. 

Typd^J^ « if A is of the form then 
« «■(■ 

[] hTt 

[E] [vf:T 

A* [E] 7JKPI^[V]:LA0 

where E must be a Constant expression of an 
integral type whose value is V 
Abstract j3arameters F->T 
A* Abstract_parameters 7)^F->LA') 

where the determination of the functional- 
ity type F Is deferred to later discussion 
under the heading Function Parameters 
(A') />7w(LA') 

Mode of declared names. Each declared name has a mode, 
determined as follows. 

// the Declarator is a Structure^member: 

The mode of 
the name is if 

field the name Is a (bit) field of the structured- 

member otherwise. 
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if the Declarator isiKzA a Structure member: 



The mode of 










the name is 


rf 








typedef 


the storage class is 


typedef; 


fen 


the storage class is not typedef 




and T 


is a functionality type; 


var 


otherwise. 




Examples: 










static int e; 




i^ 


Mode var. 


V 


extern int f() 


; 


/» 


Node fen. 


»/ 


typedef int (*g) Ob- 


/•♦ 


Mode typedef. 


V 


struct { 










int h; 




/*» 


Mode aeaber. 


*/ 


int i:5; 




/» 


Mode field. 


»/ 


} j; 




/* 


Mode var. 


V 


static int k() {} 


/* 


Mode fen. 


*/ 


static int (**!)(); 


/*» 


Mode var. 


V 



Incomplete types. A Declarator of an incomplete type 
must have storage class static- import and mode var, unless it 
is accompanied by an Initializer that completes the type; 
see Subsection 6.7 below. For example, ''extern struct s x; 
extern int a[];~ (where s is undeclared in the tag name 
space) is permitted, but "struct s x; int at];" is not. In the 
latter case the sizes of x and a are necessary for storage 
allocation but cannot be determined. 

Note. Since each structure member is of mode member 
or field, this rule effectively prohibits members having 
incomplete types. Since parameters are of automatic 
storage class, they too may not be of an incomplete type 
(but see below, where the apparent incomplete type [?]:T 
for a parameter is actually "T, so that the parameter dec- 
laration "char c[]; " is legal). But pointers to incomplete 
types are always permitted. The essential issue is that the; 
size of an object of an incomplete type is unknown. 
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Array types. The types [?]:T and [V]:T where T is an 
Inconnplete type are not permitted. 

Void types. No Declarator may have type Void. However^ 
an Abstraot_deolarator may have type Void. 

Functions. A Declarator of mode fen that is not part of a 
Function^def inition may /X7/have storage class static-export 
or static-private. For example^ the declaration "static 
gO;" Is not permitted. 

A Declarator of mode fen may not have its type deter- 
mined by a typedef of a functionality type. Although there is 
no implementation difficulty in this case, the restriction helps 
prevent confusing programs. 



Examples: 




typedef f (int x); 
extern f g; 
extern f h { 
X « 1; 


/* Illegal. */ 
/* Illegal. */ 
/« Were h legal, this would be a confus- ""Z 


} 
f *»pf; 
mainO { 

(*pf)(3); 


/* ing statenent; nhere does x com f fob? */ 
/*• But this is legal. V 



Function parameters. Parameters is syntactically of two 
different forms: Parameter_names_only and Abstract^parame- 
ters. In the latter case the types of the parameters can be 
given through Specifiers, and some or all of the parameter 
names may be given if the Declarator2 alternative for each 
parameter is used; see the rule for Abstractjjarameters. 
Additionally the "()" case of parameter specification is 
permitted through Abstractjiarameters. 

In the Parameter_names_only case, only the parameter 
names are given, and" the types of the parameters are left 
unspecified until the completion of the Function^definition 
containing the Parameters; see Function Definitions\i^\^SH. 
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Therefore there are three possibilities for a parameter: 
the parameter name only; the parameter type only; and the 
parameter name and type. No matter how the parameter 
names are provided^ they must be distinct from each other. 

Now to the deferred discussion of how to determine F in 
the Type Determination tables above. F is one of the four 
functionality type classes discussed in Section Concepts. 

If Parameters is simply "()" (via Abstract, parameters), F 
is (?)->T if D /s/fotpdrX of a function definition, and 0~>T if 
D /irpart of a function definition. 

If Parameters is a parenthesized list of parameter names 
(via Parameter_names_onlyX F ls(Ti,...Tn) -> T, where the Ti 
are the types of the parameters as declared in subsequent Pa- 
rameter.types in the completion of the Funotion_def inition. 

If Parameters Is a parenthesized list of one or more para- 
meter types and optionally names (via Abstract j^arameters), F 
is (Ti,...Tn)p -> L where the Ti are the parameter tyoes. If the 
list includes ". . . " at its tail, F is instead (Ti,...Tn,...)p -> T. 

Finally, if Parameters is "(void)*', F Is Op -> T. 

The types (Ti,...Tn)p ->T and (Ti,...Trw...)p -> T are known 
as prototype functionalities. The semantics of function call 
for functions of prototype functionality is quite different 
from those without such; see Section Expressions/Function 
Call>*i\\^r^ the difference surfaces. Prototypes fill a badly 
needed void In "old C: a way to provide checkable type 
information for imported functions. 

The type P -> T where T is an array, functionality, or 
incomplete type is not permitted. 

If the Declarator is part of a Function_def inition. Parame- 
ters and the Parameter_types and the Compound_statement of 
the Function_def inition are together a block. If the Declar- 
ator is not part of a Function_def inition. Parameters Is a 
block. See Function Definitions\i^\QM, 
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The only storage class permitted in the Specifiers of 
Abstract^parameters is register. 

In Abstract_parameters^ the types of the parameters are 
always given by using Specifiers In conjunction with Abstract, 
declarator or Declarator2. When Abstract_declarator is used, 
only the parameter type is specified; when DeclaratorZ Is used, 
the Oeclared_name of the declarator Is the parameter name. 

Example: "int h(float, int x);" gives a prototype 
functionality for function f where only the second para- 
meter Is named. Abstract.deolarator has been used for 
"f loaf, and Declarator2 for "int x**. In this example, 
naming only one parameter does not make sense, though it 
is allowed. When both parameters are named, an extension 
known as named parameter association (from Ada) Is 
possible; see Appendix Extens/onsi 

A parameter declared of type [?]:T or [V]:T Is not of those 
types, but is of type ••T. A parameter of a functionality type is 
not permitted. 

(The Constraints and Semantics for function calls — in 
particular, the type matching of actual to formal parameters 
— are presented in Section Expressions/Function Call^ 

Semantics 

Pointer types. An object of type **T is capable of holding 
the address of any object of type T. All pointer types occupy 
the same amount of storage. 

Array types. An object O of type [V]:T is a sequence of V 
objects of type T Indexed from 0..V-1. The size of Is 
V*(si2eof T). The address of O Is the same as the address of 
O[0]; in general, &0[I+1] = «.0[I] + 1 = the address of 0[I] plus 
sizeof (T) storage units. I.e. array elements are contiguous. 

An object of type [?]:T Is a sequence of unknown length of 
objects of type T. Its size Is unknown, but the relationship 
between its address and that of its elements Is the same as for 
[V]:T. 
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Functionality types. A name of type P -> T refers to a 
function returning type T. See Function Definition$\i^\tM for 
more Information. 

Discussion 

• An object of mode var can be assigned values. An object of 
mode fen is not a variable^ but labels function code and thus 
cannot be altered. See Section Expressions/Assignmentsi 
where only objects of mode var, field, or member can be 
assigned. 

• 4.2BSD is confused about "static int F1(); ". Calls to F1 
become calls to an external function; it is as if the declar- 
ation read "extern int F1(); ". But the function may not 
be defined in the source text containing the declaration; 
hence it is as If "extern" were /«7/written. By contrast, 
"extern int F2(); " declares an external function that can 
be later defined; this is proper. As a declaration local to a 
function, 4.2BSD allows "static int f();" to mean 
exactly "extern int f (); ". 

4.2BSD also allows the declaration "extern int f() {}" 
which essentially says that f is declared elsewhere ("ex- 
tern") but is actually declared right here ("O")! X3J11 
requires another declaration of f() elsewhere without 
"extern". 

Basically, C is somewhat confused with respect to impor- 
tation and exportation and the use of extern. High C 
interprets extern strictly as "defined elsewhere". 

• KR prohibits the following types: P->T, where T is a func- 
tionality, array, structure, or union type; [?]:T' or [V]:T', 
where T' is a functionality type; or structures or unions 
containing functions. Curiously, X3J11 does not impose 
any of these restrictions, but does not ascribe semantics to 
the cases where T is a functionality or array type, or where 
T* is a functionality type. 

Parameter scoping. KR does not address the issue of the 
scope of parameters. X3J11 and this document agree in spe- 
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clfying that the parameters are contained In the sanne block 
introduced by the Compound_statement of a Function_defini- 
tion. By contrast, 4.2BSD allows re-declaration of a parame- 
ter in the Cocnpound_statefnent^ a "feature" that can lead to 
agonizing bugs^ as in 

int f(a,b) 

int a; char *b; 

{ 

int x; char »b; 

X = a+b; /** Was the parameter b meant here? ♦•/ 

return x; 

} 

Type names as parameters. Note that Abstract_para- 
meters uses the nonterminal 0eclarator2^ which replicates the 
Declarator syntax except that the declared name can only be 
an <IDENTIFIER>, rather than a Name, which can be either an 
<IDENTIFIER> or a <TYPEDEF_NAME>. Likewise, Parameter^name 
can produce just <IDENTIFKR>. This means that a function 
parameter cannot be an identifier previously declared of mode 
typedef. 

Examples: 

typedef enijii{False, True} Boolean; 
void f1() { 

char Boolean; /» is legal. */ 

} 

void f2(Boolean); /» is legal. */ 

void f3(Bylyean); /» is legal. */ 

void f4(int Boolean) /» is illegal. */ 

{} 
void f5(Boolean) 

int Boolean; /* is illegal. V 

{} 
void f6(Boolean i); /» is legal. */ 

The main reason for the restriction is exemplified by the 
declarations f2 and f3. f3 declares an external function f3 
whose parameter is named Bulyean and is of type Signed- Int. 
Without the restriction, f2 could be interpreted as either a 
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function taking a paranneter nanned Boolean of type Signed- Int^ 
or a function taking an unnanned paranneter of type Boolean. 
The restriction resolves the ambiguity. 

In declaration f5^ even though it is clear that the para- 
meter's name is Boolean^ the information is available too late 
(at the second occurrence of Boolean) for proper parsing. So, 
even though this case is not ambiguous, the restriction eases 
the translator's work. 

Division of labor between Deolarators and Specifiers. 

Declarators are a way to declare a name, and optionally parti- 
cipate in the construction of the type of the nanrie. Here the C 
language is confusing: the task of specifying the type of a 
declared name is divided between Declarators and Specifiers. 

Specifiers permit the reference to and the construction 
of a structure, union, and enumeration type, or a reference to 
any of the basic types or a previously defined typedef type. 
Declarators permit the specification of array, function, and 
pointer types. 

The stated reason for placing some of the type specifi- 
cation in Declarators is that it is possible thereby to make the 
declaration of a type appear similar to the use In expressions 
of objects of the type. Any type whose use and definition could 
be made similar was placed in Declarators; all other types 
were placed in Specifiers. 

This in fact can make C declarations difficult to read, and 
the type of an object difficult to discern, it can also cause 
problems for novices: Many times this author has construed 
"char* x^y;" as the declaration of two variables of type 
"Signed-Char. But since the •• is part of the Declarator, not 
the Specifier, y is of type Signed-Char. By contrast, in 
"struct {...} >c y; ", both x and y are of the same aggregate 
type. 
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6.6 Function Definitions ■ 

[MTMittr MMs mi tfftt; dksUKtjviMttrs; SHdfiirs; fwctiiMlity typts »d 
prititypi fwctiMMlitits; rnisttr pvtmtirs; FmctiMLtftfiRitiM; irnNtnt 

coflvirsiM It functim ntry] 

syntax^ 

Funotion_definition 

-> Function: Declarator Parameter_types Compound^statefnent 

Parameter_types 

-> ( Specifiers (Parameter: Declarator list *, ')? '; ' )*• 

Constraints 

The Declarator D In a Function_definition must be of a 
functionality type P->T. The Parameters In D, the Parameter^ 
types^ and the Compound^statement, all constitute a block. 

The only Storage_class allowed In the Specifiers preced- 
ing a Parameter: Declarator is register. 

Parameters is syntactically of two different forms: Para- 
meter_names__only, and Abstract^parameters. 

Using Abstract^parameters. The Declarator2 form (see 
the rule for Abstractjarameters) must be used for each para- 
meter so that the parameter name is supplied. Furthermore^ 
Parameter_types must be empty. 

Using ParaMeter^names.only. If there are one or more 
Parameter: Declarators in Parameter_types, the Declared_name 
N of each such Declarator must not be the same as that of any 
other such Declarator^ and each Declared.name N must be one 
of the parameter names. In this case parameter N has the 
type denoted by the Specifiers and Parameter: Declarator. If 
no Parameter_type declaration is given for a parameter name 
p, the Parameter_type declaration "int p; " is implied, i.e. the 
parameter has type Signed- Int and storage class automatic. 
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Note, These rules permit other names not in the ordinary 
name space to be declared in the Parameter: Declarators: 
structure tags and member names. 

Example: 

int f(a,b) 

struct s {int z;} a; 
{^. 

Here s is declared as a tag and z a structure member, in 
addition to the declaration of the parameter a. Since there 
is no Parameter.type for b« "int b; " is implied, it is also 
possible to give just Specifiers alone with no Parameter: 
Declarator; e.g. "struct s2 {int •; }; " Is legal before the 
opening { of the function. 

The Storage.class extern may not be used with a Func- 
tion.definition^ since it is inconsistent: extern implies the 
declaration is elsewhere^ yet the function body is supplied as 
the Compound.statement. 

Semantics 

A Function_def inition provides the code body for an object 
of a functionality type, lif the storage class of the declared 
name N is static-export any other declaration of a name N 
with mode fen and storage class static- import in any other 
source text refers to this code body; see Section Concepts/ 
Independent Translation. 

If a function F does not have prototype functionality, 
actual arguments corresponding to parameters of type Signed- 
Char, Unsigned-Char, Signed-Short-Int, Unsigned-Short- Int, 
or Float are assumed to have been passed as their converted 
counterparts according to the rules of a function call (see 
Section Expressions/Function Callj, and are converted back to 
the declared formal parameter type at the outset of the 
execution of the function body. 

More precisely, for a parameter of type Signed-Char or 
Signed-Short-Int, it is assumed that the argument is passed as 
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Signed- Int^ and so conversion from Signed- Int to the parame- 
ter type occurs. For a parameter of type Unsigned-Char or 
Unsigned-Short- Int, It Is assumed that the argument Is passed 
as Unsigned- Int, and so conversion from Unsigned- Int to the 
parameter type occurs. For a parameter of type Float, it is 
assumed that the argument is passed as Double, and so conver- 
sion from Double to Float occurs. 

The Storage.class register supplied for a function 
parameter is a request that the parameter be held in a register 
during the execution of the function; it does /^^ affect the 
semantics of the program. A program with register declara- 
tions must have the same meaning as v/hen the Storage^olass 
register is arbitrarily omitted. 

Discussion 

Prototype functionality Is new, designed to allow some 
type- checking across separate compilation units. If a non-de- 
fining declaration for function F precedes a function definition 
for F, our rules for duplicate declarations (see Section Con- 
cept^ require that both have identical prototype functionality 
I f e i ther have a prototype f unct i ona I i ty . 

X3J1 1 instead adopts the notion that a prototype function- 
al ity for the first declaration and a non-prototype functional- 
ity for the second are permissible, where the semantics of the 
second are as if it was declared with a prototype functionality: 

int f (float x); 
int f (x) float x; { 

} 
void Use_f { 

f(3.0); /*» Pass in Float, not Double. V 

} 

The X3J11 approach ruins the readability of the function 
def inition of f: now its semantics are different depending upon 
whether a prototype definition for f precedes it. High C rules 
require that the definition for f also use prototype functlon- 
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allty, retaining the property of "old C that function defini- 
tions are understandable out -of -context. 



6.7 Non-Function Definitions • 

[Non.function.definitions; Initializers and initialization] 

Syntax 

Non_function_definitions 

-> (Declarator (•»• Initializer)?) list \* 

Initializer 

-> E 

-> •{• Initializer list \* ', •? '}• 

* 

Constraints and Semant/cs 

Due to the complexity of describing the initialization of 
objects. Constraints and Semantics are combined. 

Each Declarator in Non_f unction_def initions may option- 
ally be initialized. The mode of the Declarator must be var; 
thus "extern F() « {...}" is not permitted, because F Is of 
mode fen; nor is "typedef T[3] ■ {1, 2, 3}; ", since T is of 
mode typedef. Only objects of storage class static-export, 
static-private, or automatic may be initialized. If an object 
of storage class static is initialized, the Initializers must be 
constant expressions. 

Assume the object O being initialized is of type T. When T 
is a scalar type, the Initializer consists of a single expression 
E, optionally enclosed in braces. When T is a Struct{...} or 
Union{...} type, the Initializer may be a single expression E, 
/x7/enclosed within braces. The type of E must be assignment- 
compatible with T. Semantics: is initialized with the value 
of E converted to type T. 

The remaining discussion applies in all cases excluding those 
just detailed. 
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When is an aggregate^ the Initializer is a brace- 
enclosed list of Initializers for the nnennbers of 0, written In 
increasing subscript or member order; there may be no more 
Initializers than aggregate members. If contains subaggre- 
gates, this rule applies recursively to the subaggregates. 

However, any of the non-outermost braces may be elided 
for aggregate Initialization. In this case^ the aggregate "con- 
sumes" only as many members of the Initializer as necessary 
to initialize the aggregate; the remaining members are left 
to continue initialization of the object of which the aggregate 
is a part. 

The initialization construct changes the type of the if 
is of an incomplete type [?]:T. If V is the number of elements 
of O that are initialized in the Initializer, the type of is 
changed to [V]:T. 

When string constant E is used to initialize an object of an 
array type, the type of E is /w?^ converted to "C (where C is 
the type denoted by char) as Is customary; see Sections Ex- 
pressfons/<IDENrjFIER>sdn^ Expressions/Member Selection. 

An array of characters may be initialized by a string. 
Successive characters of the string (including the terminating 
character if there is room or if no size is specified) initialize 
the members of the array. Likewise, a pointer to Signed-Char 
may be Initialized to a string, since a string is always coerced 
into its address; see Section Expressions/Constant Expressions. 

When initializing a object of a Union type, the first mem- 
ber of the union is initialized. 

These rules are more precisely described in the following 
algorithm that formally establishes the correspondence be- 
tween the Initialized object and the initializing expressions. 
The algorithm is recursive and is written in "pseudo-C; fur- 
thermore, it does not contain Initializers so that it non- 
circular ly specifies the meaning of Initializers. 

The algorithm takes as input an object V to be initialized 
and an Initializer I. The constraints that must be imposed 
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and the semantics of the initialization are marked in the algo- 
rithm. It is started with the call InitializeCV, LI). 

int Initialize (V, L Start) 

object V; Initializer I; int Start; 

{ 

let I be of the form {Ei, .,, En} or just Ei, 

where the Ei are Expressions or Initializers; 
svitch (the type T of V): 
case basic type: case*T*: 

if Estart is of the form E or {Eh 
where E is an expression^ 
Constraint: The type of E must be assignment- 
compatible with the type of the object (per- 
mits assigning an array of oharaoters into a M) 
object (where C is the type denoted by just 
"char")^ since arrays are always converted to 
pointer to the first element, or the address of 
an object into a pointer). 
Semantics: V is initialized with the value of E. 
return Start+1; 
else 

Constraint: The initialization is erroneous: 
too many braces for a scalar type. 
case [L]:T': 

if Estart. is a string S of length L-t-l or less 

(including the '\0' terminator) 
and T' is Signed-Char 

{/* Note: V+1 permits us to ignore the null V 
/* byte in S. */ 

Semantics: V[i] is initialized with S[iL 

for i i 1 Min(U length of S - 1); 
return Start+1; 

} 
else { 

f or (k-Start, i«0; k i Min(V-1, n) ; i++) 
if Ek is of the form {.J 
then{Initialize(V[iLEio1); k+*} 
else k = Initialize (V[i], L k); 

return k; 

} 
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case [?]:!•:/♦♦ Initialization determines the size V 

/* of the array. V 
if Estart is a string S of length V 
and T' is the type denoted by "char" alone 

{ , , 

Constraints: the type of V becomes [V+1 J:T'; 

Semantics: V[i) is initialized with S[iL 

f or 1 i i V; 

return Start+1; 

} 
else { 

for (k«Start, i»0; kin; i++) 
if Ek is of the form {«.} 
then {Initialize(V[iLEk. 1); k++} 
else k = Initialize(V[iL L k); 

Constraints: the type of V becomes [i+1]:T'; 

return k; 

} 
case struct {Members}: 

let the members of the structure be numbered 1 . . M 
and denoted V[1]..V[n]; 
for (k-Start, i-1; k i Min(H n)-1; i*+) 
if Ek is of the form {^} 
then {Initialize (V[iLEk,1); k++} 
else k = Initialize(V[lL L k); 
return k; 
case union{Members}: 

let V[1] be the first member of the unions- 
return Initialize(V[1 L L Start); 
/* case Parameter s->T*: — No case here, 
— since functions cannot be initialized. *•/ 
} } 

When the algorlthnr) ends, all of the Initializer express- 
ions nnust have been ''used". The value of Initialize nnust 
therefore be one nnore than the length of the Initializer list. 

All uninitialized objects of static storage class are initial- 
ized to zero. Likewise, portions of static aggregates that are 
uninitialized by Initializers are initialized to zero. Uniniti- 
alized objects of storage class automatic, or uninitialized por- 
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tions of such objects in the case of aggregates^ have undefined 
values. Initialization of autonnatic objects occurs when the 
declaration of the Initialized object is elaborated; see Section 
Statements/OoinpouncLstatement\^r the definition of elabor- 
ation and when it occurs. 

The evaluation of the expressions in an Initializer is per- 
formed fronn left-to-right. However, the order of initializa- 
tion of the components of an aggregate is undefined. This 
means that constructs illustrated by "struct {int )cy;} z = 
{1, z. x}; " are not well-defined. 

Discussion 

Both KR and X3J11 seem to allow initializing objects of 
storage class static- import. However, neither document 
ascribes any semantics to the initialization, especially in the 
situation where there are two distinct initializations for the 
same imported object. 4.2BSD uses ForTran-style named 
common as a means of sharing objects, so that it is up to the 
linker to choose which initialization specification among many 
prevails. 

X3J1 1 has adopted the position that when an automatic ag- 
gregate is partially initialized by an Initializer, the remain- 
der of the aggregate is initialized to zero. We consider this un- 
fortunate and encouraging of poor programming style. In fact, 
we begrudgingly left in the initialization of all otherwise- 
uninitialized static objects to zero because of widespread 
existing practice. Depending upon this "free" initialization 
we feel is, again, poor programming practice. 

Perhaps the reason the dependence is so widespread is that 
UNIX linkers zero- initialized otherwise-uninitialized memory 
automatically. Some operating systems do not do this and, 
rather than dedicate a lot of object module space to the zero- 
ing of uninitialized space, we would prefer the language leave 
undefined the initial value of uninitialized objects, and require 
the programmer to be disciplined enough to initialized all and 
only those objects needing it. In this way he can document what 
objects need no initialization; with standard C one cannot tell. 
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As an example of an Initial jzatioa consider the Non_func- 
tion_definition 

struct {int >cy[2]; char c[2];} z[] = { 

1, {2}, -a", 
{1. 2. 3. 'x' }. 

7 
} 



The initialization specified is as follows: 


z[0].x 


= 1; 


z[0].y[0] 


= 2; 


z[0].c 


= -a"; 


z[l].x 


«1; 


2[i).y[0] 


= 2; 


z[i].y[i] 


= 3; 


2[1].C[0] 


X 'x'; 


z[2].x 


= 7; 



z[1].c[1] is left uninitialized and therefore is set to zero. 
The sanne is true of z[2].y and z[2]. c. The type of the array z 
has been changed to [3]:Struct{...}. 

Initialize(z.L1): 

case t]:T', where T' is the struct type. 
k = Initialize(z[0LL1): 
case struot{».}: 

k = Initialize(z[0].x.I.1): 
case basic type: z[0].x « 1; 
return 2; 
lnitialize(z[0]. y, {2}, 1): 
case [2]: int: 

k - Initialize(z[0].y[0L{2h1): 
case basic type: z[0].y[0] = 2; 
return 2; 
return 2; 
k = Initialize(z[0].c,L3): 
case [2]: char: 

Since I3 is a string, 

z[0].c[0] = 'a', z[0].c[1] = 'VO*; 
return 4; 
return 4; 
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/* At this point k - 4. V 
Initialize(z[lL{t 2, 3. 'x'hl): 
case struct {..}: 

k = Initialize(z[1].>c{t2,3, 'x'hD: 
case basic type: z[1].x = 1; 
return 2; 
k = Initialize(z[1].y,{1,2,3. 'x'hZ); 
case [2]:int: 

k « Initialize(z[1].y[0L{1,2,3. 'x'hZ): 
case basic type: z[1].y[0] « 2; 
return 3; 
k « Initialize(z[1].y[lL {1,2.3. *x'h3): 
case basic type: z[1].y[1] « 3; 
return 4; 
return 4; 
k * Initialize(z[1].c.{1.2.3. •x*}.4): 
case [2]: char: 

k = Initialize(z[1].c[0L{1.2.3. 'x'h4): 
case basic type: z[1].c[0] B .*x'; 
return 5; 
return 5; 
return 5; 
/* k is no* 5. V 
k = Initialize(z[2LL5): 
case struot{^}: 

k = Initialize(z[2].>c L5): 
case basic type: z[2].x * 7; 
return 6; 
return 6; 
the type of z is [3]:T'; 
return 6; 

Thus, the outermost call to Initialize returns six. one 
more than the number of elements In the Initializer, which 
is correct, and the type of z is [3]:Struct{...}. 

char s[] - {'a', 'b'. •\0'); 

causes s*s type to be [3]:Signed-Char and specifies its initiali- 
zation it to the string -ab". This is equivalent to: 

char s[] = "ab"; 
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Note that 

char *s = {'a*, 'bV 'NO'}; 
is /7^^permitted, since s is not of an array type, but that 

char *»s « -ab"; 
has the same effect. However, 

char s[2] = "ab"; 

sets s[0] = 'a* and s[1] « 'b'; the 'NO' byte in "ab" is ignored. 
4.2BSD and KR do not allow this case, an X3J1 1 extension. 

The elision of {».}s is most useful in fully initializing arrays 
of arrays: 

int Matrix[3][3] «{ 1,2,3, 4,5,6, 7,8,9}; 

However, an upper triangular Matrix can be specified by using 
{-.}s to partially initialize the rows of the Matrix: 

int Matrix[3][3] = { 1,^3, {5,6}, {9}}; 

This produces the matrix 

1 2 3 
5 6 
9 

since uninitialized storage is set to zero. 

The Initialization of structure objects with a structure- 
valued expression is an X3J1 1 extension. 

Different strategies, in existing compilers there are two 
strategies for initialization in the presence of the elision of 
braces — • i.e. when the Initializer is not fully "braced". This 
technique, which we call top-down, differs from that of 
4.2BSD, which we call bottom-ufk 

In the top-down approach, missing braces are interpreted 
as missing from the most nested components of an object be- 
ing Initialized. Put another way, the structure of the braces In 
the Initializer matches the structure of the object being ini- 
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tiallzed from the top. If there are missing braces^ only the top 
portion of the structure of the initialized object is matched. 

In the bottom -up approach^ missing braces are interpreted 
as missing from the least nested components of an object 
being initialized. 

The following example illustrates the difference: 
struct { struct {int x;} a,b; } z[] « { {1}. {2} }; 

The trees below depict the structures of the Initialized 
object (left): and the Initializer (right): 





In the bottom -up approach, the Initializer's structure 
matches the bottom portion of the tree. The initialization is 
z[0].a.x = 1 and z[0].b.x = 1, so that z Is an array of one 
element: 




In the top-down approach, the Initializer's structure 
matches the top portion of the tree, forcing a bifurcation of 
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the top node so that z has two elements. The initialization is 
2[0].a.x - 1 and2[1].a.x « 2: 




High C supports the top-down approach because it seems 
the only approach a human can easily take. AM compilers that 
we know of^ except 4.2BSD^ use the top-down approach. The 
bottom-up approach may perhaps be an artifact of the compil- 
ation strategy used In 4.2BSD. 
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7 
Statements 

A stateme/7fs\iec'\i\es an action to be performed. 



7.1 Compound Statement ■ 

[prifM; ilaNritiM if itdiritiMs; iiitiriiixiiii ^tdirctlMS wi stattmnu] 

syntax 

Compound.statement 

-> •{• (Specified_declaration I Pragma_call I Statement)** '}' 

Statement 

-> Compound^statement 

Constraints 

When a Compound_statement is not the body of a Function^ 
definition, the Compound_statement itself forms a bloclc. 
Otherwise, a block is formed that includes the Parameters and 
Parameter_types of the Function_definition; see Section 
Dectarations/Function Definitions. 

Semantics 

Except for the goto, break, and continue Statements, the 
declarations and statements of a Compound_statement are 
executed in the same sequence as their textual presentation. 

The "execution" of a declaration is a term perhaps unfa- 
miliar to the reader. In Ada it is instead called elaboration, 
and we shall also use this term. The elaboration of a declara- 
tion consists of the initialization of the object, if an Initializ- 
er is present and the object's storage class Is automatic. 

As we have mentioned in Section Concepts/Lifetimes, 
storage for an automatic object is allocated at any entry to 
the Compound_statement containing the object's definition, so 
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that elaboration does not include storage allocation. 
Discussion 

No other C language definition we know of pernnits the 
internnixing of declarations and statennents. This flexibility 
allows the placement of declarations closer to the uses of the 
dec I ar ed obj ec t . Exampie: 

getrand(int a[100]) { 
int i; 

for (i - 1; i < 100; a[i*+] - rand()); 
} 

mainO { 

int t i a[100]; 
for (j = 1; j <= 10; j++) { 
getrand(a); 

int max » 0; /* Deolaration after statement. */ 
for (1 = 1; i < 100; i++) 

if (ali] > nwx) max = a[i]; 
printf( "Maximum of random values=%d\n^ max); 
} > 

Although one nnight argue that the internnixing buys little 
convenience, we approached it fronn the other point of view 
and saw no advantage gained by the restriction so we did not 
inapose it. Furthernnore, the approach yields a simpler seman- 
tics for the timing of the initialization of objects declared 
with initializers, and when such initialization is by-passed (via 
goto or other such jump). 

The semantics of local lifetime (see Section Concepts/ 
Lifetimeii together with the scope rules allow automatic ob- 
jects in parallel Compound^statements to overlap on a run- time 
stack for storage efficiency. 
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7.2 Expressions as Statements ■ 

[side effects] 

Syntax 

Statement 
-> EL •;• 

Constraints 

None. 

Semantics 

The expression list EL is evaluated and the resulting value 
discarded. 

Discussion 

The primary purpose of an expression as a statennent is to 
achieve a side effect, such as via a function call or an assign- 
ment. 



7.3 switch^ case^ and default ■ 

[stfNiKt piiflt; case rMfts: initiilizitiM; iliktrttiM if tftdiritiMs] 

Syntax 

Statement 

-> 'snitch* •(' EL •)• Siitch.body: Statement 

-> 'case' Case_label: (Constant: E ('..' Constant: E)?) 

•r* Statement 
-> 'default' ':• Statement 

Constraints 

The EL of the switch statement must have Integral type. 
Consider the set of Statements S that appear within the 
Switch_body but do not appear within any nested Switch^body. 
Let SC denote the subset of S whose members are labeled with 
case and SD the subset labeled with default. 

In the E. . E form of a Case^label, both Es must be of the 
same integral type and must be constant expressions such that 
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the value of the first is no greater than that of the second; 
call the values bounded by the two values the range q\ the 
Case_label. Where this form of Case_label appears In SC, the 
type of the two Es must be assignment-compatible with th 
type of EL. 

Where the Case^label of a Statement in SC Is a single E, E*s 
type must be assignment- compatible with that of EL. Fur- 
thermore E must be a constant expression. The range of this 
Case.label is the single value denoted by E. 

There may not exist two Statements In SC having over- 
lapping Case_label ranges. The size of SD must be zero or one. 
i.e. there may be at most one default within a svitch. 

case or default Statements may appear only within svitch 
Statements. 

Semantics 

When the svitch Statement Is executed, the value V of EL is 
computed, and the end of Its evaluation is a sequence point. I 
V is contained in the range of the Case.label of some State- 
ment S in SC, control is transferred to S. If no Statement In SC 
has a Case.label whose range contains V, and SD contains a 
Statement D, control is transferred to D. If no Case_label*s 
range contains V and SD Is empty, the svitch Statement has no 
further effect. 

Note. When control is transferred to some Statement S, no 
initialization of any objects of storage class automatic 
declared in Sttiitch_body Is performed prior to the control 
transfer. This Is because the declarations are not elabor- 
ated, having been "skipped over" by the control transfer. 

The execution of a case or default Statement has the same 
semantics as executing the Statement labeled by these con- 
structs. Thus a transfer to such a Statement from elsewheri 
within a svitch Statement (via, e.g., a goto, or by "flowing off 
the end" of one case onto the next) is meaningful. 
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Discussion 

The first example shows a "normar use of the svitch 
construct: 

svitch (Char_class(c)) { 

case Letter: /* Scan identifier. ♦•/ 

•hile ((c = getcO) >= 'a' && c <= 'z'); 

break; 
case Number: /* Scan number. V 

•hile ((c « getcO) >- '0' && c <- 'Q'); 

break; 
case Space: /* Scan blanks. */ 

•hile ((c = getcO) = * •); 

break; 
default: 

printf( "Illegal token. \n"); 
} 

This next exanDple points out the ill-disciplined potential of 
the svitch construct and alerts unsuspecting innplennentors to 
the construct 's full "power": 

svitch (i) default: { 

case 0: 

if (1) case 1: printf("case 0\n"); 

else case 2: printf("oase 1\n"); 

/* This loop cannot be "optimized a^ay" */ 

/« because it may be entered via switch. */ 

•hile (0) { 
int j . 2*i; 

/* Initialization will never be performed. V 
case 3: printf ("Entered a while false loop; \ 

j is garbage: %d\n", j); 

} } 
case 55. . 77: 
default: printf ("Execution of case finished. \n"); 

The last statement is executed when the first switch 
terminates; the Case_labels 55. . 77 and default are irrelevant 
..and illegal) unless the example above appears in the context of 
another switch Statement. 
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7.4 if 

[sequence point] 

Syntax 

Statement 

-> 'if '(• EL •)• Statement ('else' Statement)? 

The grammar as it stands is ambiguous. The ambiguity is 
resolved as follows: in an if Statement with an else phrase, 
the Statement following the (EL) may not end in an if State- 
ment that lacks an else. Said differently, the else is matched 
with nearest lexically preceding if without an else in the 
same Compound.statement (but not in a nested Compound_state- 
ment). Thus in 

if (1) while (1) if (1) {} else {} 
the else matches the second if. 
Constraints 

EL must have scalar type. 

Semantics 

EL is evaluated; the end of its evaluation is a sequence 
point. If it is non-zero, the first Statement is executed. If it 
is zero, the second Statement, if supplied, is executed. 

If control transfers to the first Statement or any Statement 
contained within it by any other means (such as with a goto or 
switch), the second Statement, if supplied, is not executed, and 
upon termination of the first Statement, control flows to the 
Statement after the if Statement. Likewise with control 
transfers to the second Statement: the first Statement is not 
executed. 
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7.5 while 

[sequence point] 

Syntax 

statement 

-> 'while' '(' EL ')' Statement 

Constraints 

EL must have scalar type. 

Semantics 

EL is evaluated; the end of its evaluation is a sequence 
point. If the value Is non-zero, the contained Statement is exe- 
cuted. If the contained Statement S does not transfer control 
outside of the vhile Statement, then upon S's ternn I nation the 
while Statement is executed again. 

7.6 do-vhile ■ 

[sequence point] 

Syntax 

Statement 

-> 'do' Statement 'while' '(' EL ')' ';' 

Constraints 

EL must have scalar type. 

Semantics 

The contained Statement is executed. If the contained 
Statement S does not transfer control outside of the do State- 
ment, then upon S's termination EL Is evaluated; the end of Its 
evaluation Is a sequence point. If the value is non-zero, the do 
Statement is executed again. 
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7.7 for • 

[sequence point; continue] 

Syntax 

Statement 

-> 'for* '(' First: EL? 

•;• Next: EL? 

•;• Last: EL? 

•)' Body: Statement 

Constraints 

Next, if present, must have a scalar type. 
Semant/cs 

If Next Is omitted, one Is implied. 

Except in the matter of the behavior of a contained 
continue Statement in the Body, this statement is exactly 
equivalent to 

First; vhile (Next) { Body; Last; } 

Thus, the First and Next evaluation ends are sequence points. 

Discussion 

The first expression is a convenient place to put any initial- 
ization for the loop. The second specifies a test for continuing 
the loop and perhaps an incrementation. The third usually 
specifies an operation performed at the end of the loop, such as 
an increment of a variable. 



7.8 gotos and Labels 

[liititlizttiM; scoft of Itbils; •liboratim if tftcliratifiis] 

Syntax 

statement 

-> 'goto' Target_label: Name ';' 

-> Labeled statement: Label: Name ' : ' Statement 
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Constraints 

The beginning of the Compound__stateinent of the function 
containing the Label: Name is the Name's defining point* the 
'abei is declared in the label name space. The scope of the 
rebel is the block associated with that function. Note that this 
Is an exception to the normal rule that scope extends from the 
defining point to the end of a Name's origin. There may not be 
two Identical Label: Names in the same function — labels can 
not be re-declared in a nested Compound_statement. 

The Target.label of a goto Statement must be declared in 
the label name space. 

Semantics 

A goto Statement transfers control to the Statement pre- 
fixed by the associated Target.label. 

The semantics of a Labeled_statement is the same as that 
of the contained Statement. 

Note, When a Compound_statement S is entered via a goto, 
no initialization of objects of storage class automatic 
declared within S is performed. This Is because such initial- 
ization occurs only when the declarations are elaborated, 
and the goto "skips" the elaboration. 

Discussion 

The scope of label names is different from that described 
In KR, for good reasons. Consider the function 

int f() { 
LI: ; 

{ goto L1; /* Target is the last L1. */ 

{LI: ; } 
L1: ; 
} } 

KR seems to say that the scope of the innermost Li is the 
entire function ("The scope of a label is the current function, 
excluding any sub-blocks in which the same identifier has been 
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redeclared." [K&R. p.204]). High C forbids re-declaration of 
a label within a function. 

High C constraints agree with those of X3J1 1 and 4.2BSD. 
This makes most sense since it avoids the pitfalls of the above 
example where a reader could assume the goto's target is the 
first LI instead of the third LI. If a lot of program text separ- 
ated the goto and the third L1^ the target would be difficult to 
see. 



7.9 break ■ 

[exiting a svitch, for, Hhile, or do statenent] 

Syntax^ 

Statement 

-> 'break' ';' 

Constraints 

The break Statement must be contained within a switch^ 
for, vhile, or do Statement. 

Semantics 

The break Statement terminates the execution of the 
smallest enclosing snitch , for , vhile , or do Statement. 

7.10 continue ■ 

[continuing a for, nhile, or do statenent] 

Syntax 

Statement 

-> 'continue* '; ' 

Constraints 

The continue Statement must be contained within a for, 
while, or do Statement. 
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Semantics 

The continue Statement jumps to the loop-continuation 
portion of the smallest enclosing for, vhile, or do Statement. 
More precisely, in each of the Statements 

•hlle C.) {Body: Statement; Continue.;}; 

do {Body: Statement; Continue.;} vhileU); 

for (.~) {Body: Statement; Continue;} 

a continue contained within the Body Statement and not 
contained within any contained for, while, or do Statement Is 
equivalent to a goto Continue. 

7.11 return ■ 

[result of function call] 

syntax 

Statement 

-> 'return* EL? *;' 

Constraints 

The return Statement must be contained within a function 
F. The type of EL must be assignment-compatible with F's 
return type. 

Semantics 

The return Statement causes termination of the currently 
executing function and returns control to Its caller. If the EL 
is present, it is evaluated, converted to the return type of the 
function in which it appears, as if by assignment, and this value 
Is returned to the caller. If the caller expects no value, the 
behavior is undefined. 

If EL Is omitted, no value Is returned. If a value Is expected 
by the caller, the behavior is undefined. 

An implicit return (with no EL) Is assumed at the end of 
every function. 
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Discussion 

in KR, all functions had return types, so values could always 
be returned. Returning without a value returned an undefined 
value. In our semantics, which agree with X3J1 1, potentially 
worse behavior Is pernnltted, such as abnormal program ter- 
mination. 



7.12 The Null Stateaent 

Syntax 

Statement 
-> ';• 

Constraints 

None. 
Semantics 

None. This statement is most often used to carry a label. 
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8 
Expressions 



8.1 General • 

[priceifflct, assoditlvlty in txprissions; evaluition orMr; coiwutativity, 
issodativity; expression revriting; sequence point; aritlwetic conMersions; Convert; 
extended floating-point precision; ", \ i, ", and I connutative and associative] 

Expressions are presented with full operator precedence 
and associativity rules contained unannbiguously in the gram- 
mar. Consequently there are many "chain" productions of the 
form "En -> En+i". Often, the grammar Is listed in the form 

En -> En*i -> Inter est ing_alter native 

where En -> En*i is the chain production, and Interesting^ 
alternative is actually the material to be discussed. It is 
always true that the constraints and semantics of En+i are the 
same as those of En. Therefore all references in the text refer 
to nonterminals or adjectives present in Interesting^altema- 
tive. and never refer to En*i. 

The order of evaluation of operands Is not defined unless 
specifically stated otherwise — for the (), &&, I L ?:, and com- 
ma operator. However, the evaluation of operands of an oper- 
ator must not be "interleaved": one operand of an operator 
must be completely evaluated before the evaluation of another 
operand commences. This essentially forces a "top-down" 
bent to evaluation of an expression. 

The operators **, +, &, ", and | are commutative and 
associative and a language processor Is free to rewrite any 
expression involving these operators using the commutativity 
and asociativity rewrite rules, provided that the types of the 
operands or of the results are not changed in the process. 
However, once rewriting has been done, operand evaluation 
order must be as described in the previous paragraph, so that if 
"(ei + 62) + 63" is rewritten as "ei + (e2 + 63)", the outer 
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addition requires that ei be completely evaluated before (e2 + 
63) is, or vice-versa. 

Formally, the rewriting rules and constraints on using 
them are as follows: 

• commutativity: ei op 62 <=> e2 op ei always. 

• associativity: for op InK +* &. ". \h 

(eiop 62) op 63 <-> ei op (e2 op 63) 

iff Type(eiope2) = Type(e2 op es). (C) 

Since the first (ei) and second (63) operands of the first and 
second operator occurrences, respectively, are the same, the 
condition guarantees that second and first operands of the first 
and second operator occurrences, respectively, have the same 
type, so that the types of the operands and results of both 
operator occurrences are preserved by the transformation. 

That the single condition (C) guarantees operand-type 
sameness cannot be evident without knowing the conversion 
rules that are applied to the operands of the operators before 
the operation commences. Consider the first operator. 

What is the type of its second operand on the left side of 
the <=>? Before the operation commences, both 
operands are converted to type Common(ei,e2X which is 
therefore the actual type of i^^/V^ operands, and Is the 
type Type(ei op 62) of the result. 

Now consider the second operand on the right side of the 
<=>. Its type is evidently just Type(e2 op 63). 

Therefore we arrive at the requirement that Type(ei op 
62) = Type(e2 op 63), which is just (C). 

An analysis of the first operand of the second operator 
produces the identical requirement. 

This covers half the cases. We now consider the first' 
operand of the second operator, and the second operand of the 
first operator. 
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The first operand of the second operator^ on the right of 
<=>, is of type Type(ei op (92 op 93)). But by (C), this is the 
same as Type(ei op (ei op 62)). This now reduces to Type(ei op 
62). since Comnnon(ei.Connmon(ei,e2)) = Connmon(ei,e2); see 
"the definition of Common in Section Concepts. Now the type 
of the first operand of the second operator, on the left of the 
<=>, is evidently already Type(ei op e2). 

Therefore (C) guarantees that the type of the first operand 
of the second operator is the same on both sides of the <=>. 
Similar arguments show that the type of the second operand of 
the second operator is the same on both sides of the <=>. 
Hence (C) is the only requirement necessary. 

For example, as a consequence of (C), (i+j)+k can be 
rewritten as i+(j+k) if ij, and k are all of type Unsigned- Int, 
but cannot if k is of type Double or Float. 

The only sure way of placing an order upon evaluation and 
any involved side-effects is to introduce a sequence point. 

Many operators make use of arithmetic conversions. The 
donversions are detailed in Section Concepts. Functions Com- 
mon and Widen are used to describe types to which operands 
are converted. In the sequel, when we specify that a value V is 
converted to type T by writing Convert(vj), we mean V if V is 
of type T, and the result of converting V to T by assignment- 
compatibility rules if V is not of type T. 

When operands of an operator are converted to a floating- 
point type T, and the result of the operation is type L we 
permit an implementation to choose a different floating point 
type T' having no less precision and range than T that the 
operands and result may be represented in. As far as the 
constraints of the expression are concerned, the type of the 
result remains T, but the implementation may store that 
result in T', preserving more precision. The type T' need not 
|?ven be available to the C programmer — e.g. it may even be 
of greater range and precision than Long-Double. The imple- 
mentation must provide for casting the (invisible) type T' to T 
when the context demands, as in an assignment. 
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This permission is important on architectures that have a 
natural most- extended precision and range floating point type 
in which all computation is normally done, such as for the Intel 
8087 chip, and has its main impact upon intermediate express 
ions. Example: 

double d1, d2, d3, d4, d5; 

di = (d3*d4)-(d2**d1); 

/* Here, Long-Double nay be used for calculation, possibly */ 

f* obtaining nore precision than nornal, or avoiding an error V 

/* if d3**d4 or d2»d1 exceeds the range of Double. *•/ 

/* The Long-Double result nust be cast to Double before */ 

/*♦ the assignnent takes place. */ 

d5 = (d3*d4)~(d1+d2); 

/** Furthernore, the connon subexpression d3*d4 nay be stored */ 

/* in a naxinally precise tenporary fornat for use here. ^/ 

All expressions have a type T. The result of an operation 
denoted by an expression is defined only if the computed value 
is of type T, with the exception just noted where an imple 
mentation may choose a "higher" floating-point type T*. In 
addition, if any operand of an operation is undefined, the value 
of the result is undefined. 



8.2 Comma Operator: , ■ 

[sequence point; forcing evaluation order] 

Syntax 

EL -> E •, • EL2 
-> E; 

Constraints 

The type and mode of the expression list EL is the type and 
mode of EL2 (the subscript 2 is used here for convenience of 
reference and is not part of the formal grammar). 

Semantics 

E is evaluated, then EL2; the value of EL is the value of EL2. 
The end of the evaluation of E is a sequence point. 
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8.3 Assignments: = ■ 

[right pait of assignnent; assignnent conpatibility] 
Syntax 

E -> El; 

El -> E2 

-> Lvalue: Term* Plain_assignment: '=' El 
-> Lvalue: Term' (Assignment_operator E1); 

Assignment_operator 

-> •! = • I •--=• I •&=• I •»=• I •«=• 
I •+=• I •-=• I •*=' I •/=• I •'(5='; 

Constraints 

The type T of an Assignment_expression Is the type of its 
Lvalue. The mode of the Lvalue must be var or field. 

Define the right part q\ the assignment operator as El if 
Plain__assignment is used, and "Term* op (El)" if Assignment^ 
operator is used and is of the form op= (where op is j, ", &, 
)?tc.). In the latter case "Term* op (E1)" must satisfy the 
constraints for op — discussed below separately for each op. 

The type of the right part must be assignment-compatible 
with T, or be a constant integral expression evaluating to and 
T of a pointer type. The mode of the result is value. 

Semantics 

The value V of the right part and the variable L referred to 
by the Lvalue are determined. In an unspecified order. V = 
Convert(V,T) replaces the value held by L. Where Assignment, 
operator Is used, the Lvalue must be evaluated only once. 

The value of the Assignment_expression is V. 

If V is obtained from an object that overlaps In storage 
with L, the semantics of assignment Is undefined. 
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Discussion 

Note that the requirement on the mode of the Lvalue 
prevents assignments into a name of mode typedef or fen. A 
structure member as the left side of an assignment is 
generally of mode var, not member (see Subsection Member 
Seiectionb^\QVf), so that assignments into structure members 
are permitted. Objects of mode tag or label are never 
encountered since they exist only in name spaces from which 
expressions cannot come. 



8.4 Conditionai Expressions: 7 : '■ ■ 

[sequence point] 

Syntax 

E2 -> E3 

-> Conditional_expression: 
E3 •?• EL •:• E2 

Constraints 

The Conditional_expression's first operand E3 must be of a 
scalar type. The type T of the entire Conditional_expression 
Is determined from the types Tel and Te2 of its second and 
third operands EL and E2. Tel and Te2 must be either both 
arithmetic, in which case T Is Common(TEuTE2); or the two 
must be compatible types, in which case T is either Tel or Te2 
(it does not matter which); or one must be of a pointer type P 
and the other a constant expression evaluating to zero, in 
which case T is P. The mode of the result is value. 

Semantics 

The first operand E3 is evaluated; the end of its evaluation 
is a sequence point. If it is non-zero, the value V of the second 
operand EL is determined; otherwise, the value V of the thlrd^ 
operand E2 Is determined. (Therefore, only one of El and E2 is, 
evaluated.) Convert(V,T) is the result. 
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8.5 Sequential Disjunction: || • 

[sequence point] 

Syntax 

E3 -> E4 -> E3 • 1 1 ' E4; 

Constraints 

Each operand E3 and E4 of the 1 1 expression nnust have 
scalar type. The type of the 1 1 expression is Signed- Int. The 
nnode of the result is value. 

Semantics 

Expression E3 is evaluated; the end of its evaluation is a 
sequence point. If it is non-zero, the result is one. If it is zero, 
expression E4 is evaluated. If It Is non-zero, the result is one; 
otherwise the result is zero. 



8.6 Sequential Conjunction: && 

[sequence point] 
\ Syntax 

E4 -> E5 -> E4 '&&' E5; 
Constraints 



Each operand E4 and E5 of the && expression nnust have 
scalar type. The type of the && expression is Signed- Int. The 
mode of the result is value. 

Semantics 

Expression E4 is evaluated; the end of Its evaluation is a 
sequence point. If it is zero, the result is zero; If non-zero, 
expression E5 is evaluated. If it is zero, the result is zero; 
otherwise the result is one. 
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8.7 Bjt-wise inciusive-or: | 

Syntax 

E5 -> E6 -> E5 'I' E6; 

Constraints 



Each operand E5 and E6 must have integral type. The type 
T of the I expression is Common(type of E5, type of E6). The 
mode of the result is value. 

Semantics 

Both operands E5 and E6 are evaluated and converted to type 
T. The bit-wise inclusive-or of the two operands is the result. 



8.8 Bit-wise Exclusive-or: " ■ 

Syntax 

E6 -> E7 -> E6 •''' E7; 

Constraints 

Each operand E6 and E7 must have integral type. The type 
T of the ~ expression is Common(type of E6. type of E7). The 
mode of the result is value. 

Semantics 

Both operands E6 and E7 are evaluated and converted to type 
T. The bit-wise exclusive-or of the two operands is the result. 
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8.9 Bit-wjse And: & ■ 

Syntax 

E7 -> E8 -> E7 •&• E8; 

Constraints 

Both operands E7 and E8 nnust have integral type. The type 
T of the 8c expression Is Connmon(type of E6^ type of E8). The 
mode of the result is value. 

Semantics 

Both operands E7 and E8 are evaluated and converted to type 
T. The bit-wise and of the two operands is the result. 



8.10 Equality Comparisons: == and 1= • 

Syntax 

E8 -> E9 -> E8 •"' E9 
-> E8 •!=• E9; 

Constraints 

Let Tb and Tg be the types of E8 and E9. Both Tq and Tg 
nnust be arithnnetic types^ or be of compatible pointer types 
♦*T', or one must a constant integral expression evaluating to 
zero and the other a pointer type. The type T of the entire 
expression Is Signed- Int. The mode of the result is value. 

Semantics 

Both operands E8 and E9 are evaluated. If Tb and Tg are both 
arithmetic tyoes, then the values are converted to type 
Common(TB,Tg). The (possibly converted) values are compared 
for equality (==) (inequality (!=)). The result is one in the case 
the values are equal (unequal); otherwise, the result is zero. 
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8.11 Ordering Comparisons: <><=>= ■ 

Syntax 

E9 -> E10 -> E9 •<• E10 
-> E9 •>• E10 
-> E9 '<=• E10 
-> E9 •>=• E10; 

Constraints 

The same as for the equality comparisons just described. 

Semantics 

Both operands are evaluated. If the types of both are 
scalar, the values are converted to the Common type of the 
two types. The (possibly converted) values are compared ac- 
cording to the specified relation: < for less-than, > for great- 
er-than, <» for less-than-or-equal-to, and >« for greater- 
than-or-equal-to. The result is one if the relation is true and 
zero if false. 

The comparison of two pointers is done as if they were 
unsigned integers of the appropriate length. The result is 
guaranteed only for two pointers that point into the same 
aggregate; otherwise the result is implementation-defined. 



8.12 Shift Operators: « and » 
Syntax 

E10 -> E11 -> E10 '»'E11 
-> E10 •«'E11; 

Constraints 



Both operands must be of integral type. The type T of the 
result is Widen(type of E10). The mode of the result is value. 
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Semantics 

The values Vio and Vii of E10 and E11 are deternnined. Vio is 
converted to T and Vii to Signed- Int. The value of E10 « E11 
is Vio, interpreted as a bit pattern, left-shifted Vii bits, with 
this result interpreted as type T. The value of E10 » E11 is 
Vio, Interpreted as a bit pattern, right-shifted Vii bits, with 
this result interpreted as type T. The right shift is guaranteed 
to be logical (zero-filled) If ElO has an unsigned type; other- 
wise it nnay be arithmetic (filled with a copy of the leftmost 
bit). The result is implementation-defined if Vii is negative 
or greater than or equal to the size in bits of Vio. 



8.13 Additive Operators: + and • 

[pointer arithnetic; addition, subtraction] 

Syntax 

E11 -> E12 -> E11 •+• E12 
-> Ell •-• E12; 

Constraints 

Let Til be the type of Ell and T12 the type of E12, and let R 
be the type of the result. One of the following conditions must 
obtain: 

(a) Til and T12 are both arithmetic types, in which case R is 
Common(Tii,Ti2); 

(b) one is of the form **T and the other an integral type I, in 
which case R is ♦♦T (and if the operator is '-', the first 
operand must be the one of the form *♦!); or 

(c) or Til and T12 are the same pointer type **T and the oper- 
ator is '-', in which case R is either Signed-Short-Int, 
Signed- Int, or Signed-Long-Int (which one in particular is 
implementatfon-defined). 

In cases (b) and (c), in **T, T must not be a functionality 
type. The mode of the result is value. 
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Semantics 

Both operands are evaluated. 

In case (aX the values are converted to R, and the result is 
the sunn ('+') or difference ('-') of the operands. 

In case (b), if the value V of type **T points to the i^ 
elennent of an array of type [...]:L the result is a pointer to 
elennent i+(value of type l) or i-(value of type l) of the array. 
This holds only for pointers within the bounds of the array, 
except that it is allowed to point to a hypothetical elennent 
following the array's last element. The use of the pointer 
result as an operand of * is defined only for pointer values 
within the array bounds. 

In case (c), if the two values point to the i^ and j^ 
elennents, respectively, of the same array, or possibly one past 
the end of the array, the result is i-j; otherwise the result is 
undefined, i-j must be a value of type R. 

Discussion 

The semantics of pointer arithmetic when the result 
exceeds the array bounds by one is necessary so that common C 
idiom "A[V]" for A of type [V]:T is reasonable; this semantics 
was proposed by X3J11. KR does not treat the matter. The 
4.2BSD implementation agrees with our semantics. 



8.14 Multiplicative Operators: * / % • 

[nultiplication, division, nodulo] 
Syntax 

E12 -> E13 -> E12 '*' E13 
-> E12 •/' E13 
-> E12 •%• E13; 

Constraints 

Let Ti2 be the type of E12 and T13 the type of E13. Both 
operands must be of arithmetic type; the type T of the result 
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is Common(Ti2Ji3). For the operator %, each operand must be 
of integral type. The mode of the result is value. 

Semantics 

Both operands are evaluated and converted to type T. 

If the operator Is ^, the result is the product of the two 
values. 

If the operator is A the result is the quotient. If the 
operands are both of integral type and the result of the division 
is not an integer, the result is as follows: if both operands are 
positive, the result is the largest integer less than the true 
quotient. If either operand is negative, the result Is either the 
greatest integer contained in or the least integer containing 
the true result; which one in particular is. implementation- 
defined. 

The result of the operator X for values a and b Is a - 
(a/b)**b, where / is the division operator explained above. 



3.15 Type Casts ■ 

Syntax 

E13 -> Term; 

Term 

-> Term* 

-> •(' Cast^type ')' Term 

# 

Constraints 

The Cast^type must be of a scalar type C or type Void, and 
the term must be of some scalar type T, unless casting to 
Void. The type of the result is C. The mode of the result is 
value. 

Semantics 

The value V of the Term is determined. 
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If T is a pointer type and C sonne integral type^ the result is 
undefined if an object of type C cannot hold V. Otherwise the 
result is V. 

If T is Sonne integral type and C a pointer type, the result is 
undefined if an object of type C cannot hold V. Otherwise the 
result is V. 

If T and C are both pointer types to functions, the result is V. 

If T and C are both pointer types to non-function objects, 
the result may not be defined if the alignnnent for C is nnore 
restrictive than that of T. Otherwise, the result is V. 

Otherwise, the result is Convert(V,T). 

Discussion 

The semantics of pointer conversion requires that pointers 
to non- function objects be the same size. 

Subset Term* of Term has been introduced to capture the 
relative precedences of the cast syntax and of sizeof : sizeof 
binds more tightly than a cast. Therefore "sizeof (int)*x" is 
the same as "(sizeof (int))*^". 

Casting to Void Is most often used to discard the result of 
a function, when writing an expression that is a function call. 



8.16 Pointer Dereference: * 

[pointer alignnent] 

Syntax 

Term' 
-> T1 
-> <•*'> Pointer: Term 

Constraints 



The Pointer must be of a type of the form "T. The type 01 
the result is T, except where T is of the form []:T', in which 
case the type of the result is •♦T'. The mode of the result is 
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var unless T is a functionality type, in which case the nnode is 
value. T must be neither an inconnplete type nor Void. 

Semantics 

The value V of the Pointer Is determined. The result is the 
object pointed to by V. If V is zero the operation is undefined. 

Through type casts it is possible to obtain a pointer value V 
that is inappropriately aligned for the pointed- to type T. V is 
therefore not a valid value of type ♦*T and therefore the oper- 
ation *V is undefined. 

Discussion 

4.2BSD allows *"f, for n i 1, to denote "f for a value f of 
functionality type. High C prohibits such, as do KR and X3J1 1 . 



8.17 Pointer Reference: & — ■ 

[conversion of arrays to pointers; address of an array] 

Syntax 

Term* 

-> •&• Term 

Constraints 

The Term may be of any type T. The result is of type »T. 
The Term must be of mode var, and may not denote an object 
declared with Storoge^class register. The mode of the result 
is value. 

Note. If Term is of an array type, the normal conversion of 
its type to "T is not done; see Subsections <E€NTIFIER>s 
and i^ember Setection\i^\^\n . 

Semantics 

The result Is a pointer to the Term. 
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Discussion 

Note that taking the address of a structure -field is prevent- 
ed because fields are of mode field. 

The constraints prohibit &F, where F is a function nanne, 
since by the function conversion rules (see Subsection <IDENTI' 
FlER>s below), F is converted to the address of F of nnode 
value. Most connpilers sinnply warn when 8.F is used; 4.2BSD 
pernnits &"V. for n 1 1, to denote &V, but High C disallows such. 

X3J11 introduced the ability to take the address of an 
array expression, where in KR the autonnatic conversion of 
array expressions to pointers to the first element made this 
impossible. The added ability allows the construction of an 
pointer of type "[JrT from an (array) expression of type [1:T. 
Previously It was only possible to obtain type []:**T, and "U^T 
had to be obtained through casting. Examples: 

int a[10]; /* Type []: Signed- Int. */ 

void f(int (*arg)[]) {...> 

/* Paraneter is of type •[]:Sioned-Int. */ 

f (a); /«• Illegal: argument is of type "Signed- Int. */ 

f ((int(*)[])a);/* Old, tedious way of getting around problen. */ 
f (&a); /* Neu: obviates need for cast. */ 

typedef t[10]; 

t a; /* Declare an array. */ 

t *b = &a; /•• Initialize b to the array's address. */ 

t *c = (t *)a; /* Equivalent, old nethod. */ 



V. 1 1 . 01 . 85 © 1984-85 lietaUare Incorporated 



Expressions page 8-17 

8.18 Unary Sign Operators: - and + ■ 

[negation] 

Syntax 

Term' 

-> '-• Term 

-> •+' Term 

Constraints and Semantics 

Same as those of (0-Term) and (0+Term), respectively. 

Discussion 

Note that "+x'' is not necessarily the same type as >c if x is 
of type Slgned-Char^ "+x" is of type Signed- Int. 



8.19 Bit-wise Complement: " • 

Syntax 

Term' 

-> •~' Term 

Constraints 

The Term must be of an integral type T. The type of the 
result Is Widen(T). The mode of the result is value. 

Semantics 

The Term is evaluated and converted to type Widen(T). The 
result is the bit-wise complement of the value. 



8.2Q Boolean Negation: ! 
Syntax 

Term* 

-> ' ! ' Term 



Constraints and Semantics 

Same as for the expression (0 == Term). 

V. 11.01.85 © 1984-85 HetaUare Incorporated 



Expressions page 8-18 

8.21 sizeof - 

[conversion of arrays to pointers; byte] 

Syntax 

Term* 

-> 'sizeof (•(' Cast_type ')' | Term') 

Constraints 

Term* may not be of mode field. Let T be the Cast_type, or 
the type of the Term* . T must be neither Void nor any function- 
al ity type nor any incomplete type. The result is of an integral 
type; which one in particular is implementation-defined. The 
mode of the result is value. 

Note. If Term' is of an array type, the normal conversion 
of Its type to "T is not done — see Subsections <IDENTI- 
FlER>sdx\^ Member Se/ect/onhe I ow. 

Semantics 

Where Term' is used. It is z?^/" evaluated. In any case th 
result is a non-negative Integer that is the number of bytes re- 
quired to hold a value of type T. It Is true that sizeof ([V]:T) = 
V**sizeof(T) and that sizeof(Signed-Char) = sizeof(Unsign- 
ed-Char)= 1. 

Discussion 

The reason that the automatic conversion of array types to 
pointers is avoided is so that it is possible to obtain the size of 
an array, rather than the size of a pointer to the array's ele- 
ment type. Example: 

char d[10]; 

int j = sizeof (a); /* j is initialized uith 10. *♦/ 

void f(char b[]) { 
int k = sizeof (b); 

/^ k is initialized uith the size of a pointer to char, since * 
/* a's declaration is adjusted to read "char *a;". The sane *♦/ 
/^ initial value would be supplied for j above if we did not */ 
/* defeat the nornal conversion of array types. */ 

} 
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8.22 Prefix Increment and Decrement: ++ and — -- ■ 

[addition, subtraction] 

Syntax 

Term* 

-> T1 

-> '++• Lvalue: Term 

-> • — • Lvalue: Term; 

Constraints 

The Lvalue must be of mode var or field and scalar type T. 
The result js of type T and mode value. 

Semantics 

The Lvalue is evaluated. The value held by the object refer- 
enced by the Lvalue is incremented (++) (decremented (— )X 
i.e. one is added (subtracted), with the semantics of addition 
(subtraction) described above. The result is the incremented 
(decremented) value. 



8.23 Postfix Increment and Decrement: ++ and ~ - ■ 

[addition^ subtraction; side-effect, sequence point] 
Syntax 

T1 

-> Lvalue: T1 '++* 

-> Lvalue: Tl • — '; 

Constraints 

The Lvalue must be of mode var or field and scalar type T. 
The result is of type T and mode value. 

Semantics 

The Lvalue is evaluated. The result is this value. The value 
held by the object referenced by the Lvalue Is incremented (++) 
(decremented (— )), i.e. one is added (subtracted), with the 
semantics for addition (subtraction) described above. 
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The incrementing (decrementing) operation is a side-effect 
so it can be postponed until the next sequence point. 



8.24 Function Call: () • 

[functionality type and prototype functionalities; argunent type 
checking; variable nunber of argunents to a function; recursive 
functions; Pascal function call senantics; sequence point] 

Syntax 

Tl 

-> T1 •(' Arguments ')'; 

Arguments 

-> (E list •,*)?; 

Constraints 

If Tl is a Name that is undeclared In the ordinary name 
space, the occurrence of the Name becomes Its defining point In 
the ordinary name space as a function of type F « (?) -> Sign- 
ed- Int with storage class static- import and mode fen. If so,, 
this replaces the normal constraints for the Tl, which require 
that the Name is declared. The scope for this Nome extends from 
its defining point to the end of the program, which differs 
from normal block-structured scope rules. 

Otherwise, Tl must be of some functionality type F. 

F is one of the following four forms; see Section Concepts: 

(a) (?) -> T for T a type; 

(b) (Ti,...Tn) ->T \ 

(c) (Ti,...Tn)p ->T I for T,Ti,...Tn types, n>0. 

(d) (Ti,...Tn,...)p ->T / 

In all of the cases, the type of the result (of the function 
call operator) Is T. Its mode is value. 

In cases (a) and (b) the Arguments may be of any type. Even 
though the types of the function's parameters are specified In 
case (b), a language processor may at most warn if the type of 
an argument does not match the type of a parameter. 
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In case (c), there must be n Arguments. The type of the i^^ 
Argunnent must be assignment-compatible with Ti. 

Case (d) is the same as case (c) except there may be more 
than n Arguments. The additional Arguments may be of any type. 

Semantics 

The TI and the Arguments are evaluated in an unspecified 
order. The end of the evaluation of the Arguments is a sequence 
point. The end of the evaluation of the call is a sequence point. 

For each of the Arguments A of type Ta and corresponding 
parameter type L A is converted as if by assignment to a 
variable of type T. When T is unknown^ which occurs in cases 
(a) and (bX and for the additional Arguments in case (d), T is 
implied by Ta as follows. T is 

• Signed- Int If Ta is Signed-Char or SIgned-Short-Int; 

• Unsigned- Int if Ta is Unsigned-Char or Unsigned-Short- Int; 

• Double if Ta is Float; or 

• Ta otherwise. 

Note that since an expression of type [?]:T' or [V]:T' is 
converted to type "T', Ta can never be of an array type [?]:T' 
or [V]:T'. Likewise, Ta can never be a functionality type T*, 
since it is converted to **T'. 

The function is called with its parameters taking on the 
converted values of the Arguments. The call is by value: copies 
of the values are passed. Thus, assignments into a function's 
parameters within the function body do not affect the Argu- 
ments passed. 

Direct and indirect recursive calls to any function are per- 
mitted. 

Discussion 

E instead of EL is used in the rule for Arguments to avoid an 
ambiguity. 
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Early C compilers never made any check for parameter 
correspondence. Arguments of integral type were simply wid- 
ened, and Floats were converted to Double. The specification 
of parameter types in a Function^definition had no effects. 
argument passing. 

To preserve these semantics, a functionality type F affects 
argument passing only when F is a prototype functionality. 
When using a prototype, short integer and Float arguments can 
be passed more efficiently; the old semantics requires the pos- 
sibly expensive conversion of Float to Double and the shorten- 
ing of integers. 

Furthermore, an integer argument may be passed to a func- 
tion receiving a Float parameter, and the argument is conveni- 
ently converted to Float. Essentially, prototype functionali- 
ties are C's concession to the safer procedure call semantics 
of Pascal. Example: 

Inefficient: int f(x,c) float x; short s; {...} 
f(3.2,3); 

Efficient: int f (float x, short s) {...} 
f(3.2,3); 

In the first case, a Double and Signed- int are passed and f's 
prologue converts the Double back to a Float and the Signed- 
Int back to Signed-Short-lnt. In the second case, a Float and 
Signed-Short-Int are passed and no conversion occurs in f's 
prologue. 

X3J11 provides that the scope of an implicitly-defined 
function F is the innermost block containing the call to F. We 
have instead made its scope the entire program. This prohibits 
an inconsistent declaration of F from appearing at the global 
lever later, such as in 

main () { /* Implicit declaration of f *♦/ 
f(); /* as extern int f(); */ 

} 
long f() { ...} 

/* Illegal: long != int. V 
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Note that the declaration "int f();" and "int f(...);" 
are equivalent. The unfortunate duplication of syntax is due to 
compatibility with "old C". 



8.25 Array Indexing: [ ] ■ 

[pointer arithnetic] 

Syntax 

T1 

-> T1 •[• EL •]• 

Constraints and Semantics 

Same as for (♦* ((T1) + (EL)) ). 

Discussion 

[] Is intended to be used to subscript an array. Because of 
the semantics of + in the equivalent expression (♦♦ ((T1) + 
(EL)) ), T1 can either denote an array or a pointer to an array; 
if the former^ it is immediately converted to a pointer to the 
first element of the array. The +(EL) moves to the desirtd 
element of the array, and the outer * extracts the value. The 
reader may wish to verify that the mode of the result will 
always be var. 

Therefore, If P is a pointer to the first element of array A, 
P[EL] and A[EL] denote the same object. Also, (EL) [A] and 
A[EL] are the same. 

A[I, J, K] has unexpected semantics. It is the value of A[K] 
after I and J have been evaluated. Do not read A[L J,K] as 
subscripting a three-dimensional array: there are only one- 
dimensional arrays in C. 
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8.26 Pointer Dereference and Member Selection: -> ■ 

Syntax 

T1 

-> T1 •->• Member: Name 

Constraints and Semantics 

Same as for (*»(T1)).Name. 

Discussion 

This notation is provided as a shorthand for the cunnber- 
sonae notation (*p).f, where p is a pointer to a structure or 
union value and f is the nanne of a nnember of the value. The 
weak binding of the operator * makes necessary the () around 
the *p, for *p. f means *(p. f ). 

8.27 Member Selection: . ■ 

[sizeof, 6; struct, union] 

Syntax 

T1 

-> Primary 

-> T1 '. ' Member: Name; 

Constraints 

The type of T1 must be of the form Struct{M} or Union{M}. 
In particular, no incomplete structure or union types are per- 
mitted. The type must have a Member m named Name. 

The type of the result is the type T of m, unless m is of an 
array type [...]:T and the selection is not an argument to 
sizeof or &, in which case the type of the result is "T. 

If the latter case holds or Tl is of mode value, the result i« 
of mode value. Otherwise, if the mode of m is field, the 
resulting mode is field; otherwise the resulting mode is var. 
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See Subsections Pointer Reference and sizeof for the 
reasoning behind not converting type T to •♦T in the presence of 
sizeof or &. 

Semantics 

The Primary Is evaluated. The result Is the value of the 
designated structure or union Member, except when T is an array 
type. In which case the result Is the address of the first 
elennent of the array. 

In general, a Member of a union nnay not be inspected unless 
the value of the union was assigned using that same Member, 
with the following exception: if a union contains several struc- 
tures that share a connmon initial sequence, and if the value of 
the union was assigned using one of those structures, it Is 
pernnitted to inspect the comnnon initial part of any of them. 
(This follows X3J11.) Example: 

union { struct {int Type; } N; 

struct {int Type; int IntNode; } NI; 

struct {int Type; int FloatNode; } NF; 
} U; 

U.NF.Type = 1; U.NF. FloatNode = 3.14; 

if (U.N. Type == 1) U.NF. FloatNode = -U.NF. FloatNode; 



8.28 Overriding Operator Precedence: ( ) 

Syntax 

Primary -> '(' EL *)•; 

Constraints and Semantics 

Same as for EL. 
Discussion 



Mere parenthesization does not change the constraints or 
semantics of an expression. For example, if EL is of mode M 
and type T, so is the result. 
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8.29 <IDENTIFIER>s ■ 

[sizeof , G; conversion of arrays to pointers; <IOENTIFIER>] 

Syntax 

Primary -> Name: •<IDENTIFIER>'; 

Constraints 

The Name must denote an object of sonne type T and nnode M 
in the ordinary nanne space. If T is of the form [...]:T' and the 
Name is not an argument to sizeof or &, the type of the result 
is "T'; if it is of a functionality type T and mode fcn^ the type 
of the result is **T; the mode of the result is value. Other- 
wise the type of the result is T and its mode is var. 

See Subsections Pointer Reference and sizeof for the 
reasoning behind not converting type T to "T In the presence of 
sizeof or &. 

Semantics 

The value of the Primary is generally the object denoted by 
the Name. However, if T is an array type, the value is a pointer 
to the first element of the array; if a functionality type, the 
entry point of the function. 

Discussion 

Primary directly produces <IDENTIFIER> rather than the 
nonterminal Name so that <TYPEDEF_NAME>s are disallowed in 
expressions. The mode of an <IDENTIFIER> can never be type- 
def since any such an <IDENTIFIER> is instead in the lexical 
class <TYPEDEF_NAME>; therefore the constraints need not pro- 
hibit mode typedef. 
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8.30 Constants ■ 

r<INTEGER>, <FLOAT>, <CHAR>, <OCTAL>, <HEX>, <STRING>; String 
ierninator; arrays of characters] 

Syntax 

Primary 

-> Constant; 

Constant 

-> • <INTE6ER> • I * <FLOAT> ' | ' <CHAR> * | ' <OCTAL> ' I ' <HEX> ' 

-> XSTRING)'*; 

Constraints 

The mode of each Constant is value. Other constraints 
detailing each Constant's type can be found in Section Lex/con. 

The constraints of two or more <STRING>s appearing in 
sequence are equivalent to a single <STRING> whose text is that 
of the individual <STRING>s concatenated, but without a separ- 
ating '\000'. 

Semantics 

The value of two or more <STRING>s appearing in sequence 
is the same as that of a single <STRING> whose text is that of 
the individual <STRING>s concatenated, but without a separat- 
ing '\000'. A single 'NOOO* is appended to the concatenation 
and the result is the value of the <STRlNG>s, as if a single 
<STRING>. 

Strings do not share storage with each other, even when 
written identically. 

Discussion 

Strings are arrays of characters, and as arrays are usually 
converted to a pointer to the literal. See Section Lexicon. 

String concatenation is contained only in X3J11 and this 
definition. 



V. 1 1 . 01 . 85 © 1984-85 HetaUare Incorporated 



Expressions page 8-28 



8.31 Cast Types and Abstract Declarators 

[Abstract_declarator] 

Syntax 

Cast^type 

-> Type_specifiers Abstract_declarator? 



Constraints 

The occurrence of a Cast_type is associated with a type T' 
that is specified in the Type_specif iers preceding the optional 
Abstract_declarator. The type T of the Cast__type is T' if the 
Abstract__declarator is not written; otherwise, it is Type 
(T',A), where A is the Abstract_declarator and the definition 
of Typemd^y be found in Section Declarations/Declarators. 

Semantics 

None. This is purely a type-specifying construct. 

Discussion 

In C the type of an object is specified both in Type and 
Declarator. For exannple, a pointer type is constructed in a 
Declarator, not a Type. But since a Declarator always declares 
a name. It is not possible to use it to describe a type without 
declaring a name. 

Hence the invention of the Abstract_declarator. It Is like 
a Declarator except the name is missing. The type of the 
missing name is the type denoted by the Abstract_declarator. 

The unfortunate near-duplication of syntax in Abstract^ 
declarator could have been avoided were all type information 
provided In Type, rather than splitting it up Into Type and 
Declarator. Then '(' Type ')' could have been used for a 
Cast_type. 
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8.32 Names ■ 

[<IOENTIFIER>, <TYPEOEF_NAHE>] 

Syntax 

Name -> '< IDENTIFIER >' I '<TYPEDEF_NAME>'; 

The reason for '<TYPEDEF_NAME>' as an alternative for Name 
is that an identifier already declared of nnode typedef is lexi- 
cally a •<TYPEDEF_NAME>' instead of an '<IDENTIFIER>'. Thus, 
consider: 

typedef int T; /♦♦ Occurrence 1 of T. *♦/ 

mainO { 

T x; /♦♦ Occurrence 2 of T. V 

int T; /*♦ Occurrence .3 of T. */ 

> 

Occurrence 3 is a redeclaration of T as a variable of type 
Signed- Int. Due to the outer typedef declaration^ occurrence 
3 is a <TYPEDEF_NAME>. This essentially reflects a sinnple inn- 
plementation of a C processor front-end: the lexical processor 
looks up each <IDENTIFIER> to see if it is a <TYPEDEF_NAME>, and 
if so. changes it to a <TYPEDEF_NAME>. The <TyPEDEF_NAME> lexi- 
cal class is necessary for the proper parsing of declarations 
using <TYPEDEF_NAME>s, exemplified by occurrence 2. 

Constraints and Semantics 

None. The constraints for a Name are given where Name is 
used in the syntax. 

8.33 Constant Expressions ■ 

[arriy size; bit-field length; enuneration litertl; cut constant; initialization] 

In several places the C language requires an expression E 
that evaluates to a constant. Repeated here for convenience, 
they are: the size of an array or bit-field, the value of an 
enumeration constant, a case constant, and the initialization 
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of an object of storage class static. All but the last case are 
constrained to be of an integral type. 

The following subset of well -formed expressions are con- 
stant expressions when each E is a constant expression: 

• E ? E : E 

• E op E, when op is one of the binary operators 

& ^ I && II 

• op E, when op is one of the unary operators 

+ - *" ! sizeof 

■ ( Cast_type ) E 
■(E) 

■ <IDENTIFIER>^ when declared as an enunneration literal 

• any of <INTE6ER> <CHAR> <OCTAL> <HEX> <FLOAT> 

For constant expressions required to be of an integral type, 
<FLOAT> is excluded, and Cast_type must denote an integral 
type. 

Constant Initializers can also employ 

• the application of & to objects of storage class static 
and to arrays of storage class static subscripted with a 
constant expression 

" an identifier declared of mode fen 

■ an identifier declared of an array type 
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Appendix A 
Language Extensions 

A.l Introduction 

This section presents features in the fHIgh C language not 
typically found in implennentations of C. These extensions fall 
into three categories: 

■ extensions that X3J1 1 has nnade to C, 
• simple High C extensions, and 

■ radical High C extensions. 

The first two classes of extensions are documented in the 
main body of this reference work. The last is documented only 
here — not, however, because the radical extensions are unim- 
portant. Rather, they are too different to Include In the main 
)ody of the language definition. Hence they were relegated to 
this appendix so that those readers not interested In them 
would not to have to skip over them. 

For completeness, the first two classes of extensions are 
discussed briefly in Subsections A.2 and A.3. The third class is 
treated at length In Subsections A.4 through A.7. Finally, the 
last subsection Is a brief tutorial on the X3J11 extension, 
function prototypes. 

A.2 X3J11 Extensions to C 

['V as lim continuator; string concatination: constant soffixts; iscapa saqutncis; 
sliaal; lu| tftifela; aggregata initialization; function prototypes] 

• The use of '\' as a line continuator character — Section 
Lexicon. 

To overcome source line limitations, any line ending In the 
character 'X* is treated as contiguous with the following 
line. Therefore any C word may be broken across line boun- 
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claries. This is most useful for multiple- line macro defini- 
tions and long strings^ although there is a better solution 
for the latter ^ see the next Item. 

• String-constant concatenation — Section Lexicon. 

Juxtaposed string constants denote the concatenation of 
the constants. Example: 

char *p « "Hi " "there. " 
"folks. "; 

is equivalent to 

char *p = "Hi there, folks. "; 

This feature Is useful for long string constants that span 
more than a line of text, and for aligning portions of a 
string to emphasize or illuminate correspondences. 

• Vertical tab as a delimiter — Section Lexicon. 

The ASCII vertical tab character is semantically equivalent 
to a blank when not appearing within a string or character. 

■ Suff ixes u (u), 1 (l) In integer constants — Section Lexicon. 

These suffixes, either alone or together, in either order and 
independently in either upper or lower case, are permitted 
in integer constants: decimal, octal, and hexadecimal. The 
effect of "u" Is to change the type T that the integer con- 
stant would otherwise have to the unsigned variety of T. 
The effect of "1" is to change T to the long variety of T. 
Thus, for example, "123" has type Signed- Int, "123u" 
Unsigned- Int, "1231" Signed- Long- Int, and "I23ul" and 
"1231u" Unsigned- Long- Int. 

■ Suffixes f (F), 1 (l) in float constants — Section Lexicon. 

The suffix 1, in upper or lower case. Is permitted in float- 
ing-point constants. Its effect is to make the type of the 
constant Long-Double Instead of the default Double. ThC, 
suffix f, in upper or lower case, makes the constant's type 
Float rather than Double, f and 1 may not appear together. 
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• Escape sequences \a, \v^ and Nxddd in strings and characters 
—•Section Lexicon. 

In addition to the escape sequences \n. \t, \b, \r. \f, \\, \'. 
\^ and \ddd (octal digits) allowed by KR, the sequences \a, 
\v, and \xddd are allowed, where \a denotes "audible alert" 
or the ASCII BEL character, \v denotes the ASCII vertical 
tab character, and ddd is a sequence of one to three hexa- 
decinnal digits (with each letter in upper or lower case): 
\xddd denotes a single byte whose value is dddi6. 

■ The new reserved word signed — Sections Lexicon and 
Dectarations. 

The type modifier signed may be used to indicate that the 
modified type Is to be signed. This is most useful in guaran- 
teeing that a char type is signed, since an implementation 
is free to decide whether the unadorned type denotation 
char denotes Signed-Char or Unsigned-Char. For example, 
"signed char c; " declares c of type Signed-Char, whereas 
"char c; " may be signed or unsigned depending upon the 
implementation. 

• New type denotation long double — Section Declarations. 

The type specifier long double denotes a new floating- 
point type Long-Double having precision and range no less 
than type Double. This may be employed to obtain a triple- 
precision floating-point type. 

■ Initialization of automatic aggregates with static express- 
ions — Section Declaration/Non-Function Definitions. 

An aggregate object O with storage class automatic may be 
initialized with the same initializing expressions permit- 
ted for static aggregates and additionally, if is a struc- 
ture or union, with a single expression of O's type. 

■ Initialization of structures with structure-valued express- 
ions — Section Dec/aration/Non-Function Definitions. 
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A structure (struct/enum) may be initialized with a struc- 
ture-valued expression, as in 

extern struct s{int x;} f(); 
mainO { 

struct s S = f (); 

} 

• Function prototypes — Sections Declarations dx\^ Expres- 
sions. 

See Subsection A.8 for an introduction to this Pascal -I ike 
concept in C. 

A.3 High C Extensions Documented in the Manual Body 

[underscores in nunbers; internixing statenents and declarations; 
case ranges; aggregate initialization; pragiia] 

• Underscores in nunnbers — Section Z^^yir^yz 

Numbers — both floating-point and integer constants — 
may be written with the character •_' among the digits. 
Generally '_' takes the place of the English comma in 
numbers. Example: 

1_000_000 /* One million. */ 

• All characters In identifiers are significant — Section 
Lexicon. 

• The ability to intermix declarations and statements — Sec- 
tion Statements. 

In a compound statement, i.e. the list of declarations and 
statements enclosed within { and \ declarations and state- 
ments may be interleaved, as opposed to declarations pre- 
ceding statements. This allows one to place a declaration 
near its first use, where its Initial value may be available. 
Example: 

int A[10]; 
Compute__array(A); 
int M = riax(A, 10); 
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With this relaxed order^ it is now possible to "execute" — 
formally^ elaborate, a term borrowed from Ada — a 
declaration more than once. Elaboration includes Initial- 
ization. Example: 

Loop: ; 

int IC Count = 1; 
for (K = 1; K <= 10; K++) { 
. . . Do_something(); . . . 

} 
goto Loop; 

Each time around the Loop^ Count is initialized to one. 

■ Case ranges in the case Statement — Section Expressions. 

High C permits the extension "case E1..E2:" where the 
meaning is equivalent to "case El: case E1+1: case E1+2: 
. . . case E2: " . Example: 

switch (Ch) { 

case 'A'..'Z*: Scan_id(); break; 

case • • . . ' 9 • : Scan_nuniber ( ); break; 
default: Scan_delimiter(); break; 

} /» The latter break for safety: V 
/* in case of reordering cases. *♦/ 

• Initialization of automatic aggregates with arbitrary 
expressions — Section Declarations. 

High C permits automatic aggregates to be initialized with 
arbitrary non-constant expressions, where X3J1 1 restricts 
initialization lists to constant expressions. 

• New reserved word pragma — Sections Lexicon, Declara- 
tions, and Statements. 
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A.4 Named Parameter Association 

[function call; positional paraneters] 

Functions declared with paranneter nannes can be called 
with the named parameter association syntax of Ada. Sucli 
calls refer to the parameter names rather than their positions, 
so that the ordering of supplied parameters Is irrelevant. The 
syntax is like that of a normal function call except that each 
actual parameter expression is preceded by the corresponding 
formal parameter name followed by "=>". Example: 

typedef enum{Red, Green, Blue} Color; 

void P(int K float B, Color C, Color D) { . . . } 

P(C => Red, D -> Blue, B -> x«»10.0, A »> y); 

One may also start the function call using positional 
parameter notation and switch to named association di^ the 
parameters are written down from left to right. Switching 
back to positional notation is not allowed, nor is any other 
variation. Example: 

void Plot(Xlo, Xhi, Ylo, Yhi, Xinc, Vine) 
float Xlo, Xhi, Ylo, Yhi, Xinc, Vine; { 

>" 
Plot(Alo, Ahi, Blo»2. 0, Bhi*2. 0, Yinc=>y, Xinc=>f (x+z)); 
The formal definition of this construct follows. 
Syntax 

To permit the => operator, add to the lexical grammar 
(Section Lexicoi^, the rule 

Other_op -> '«' •>' ->'<AS_IS>'; 

Add to the phrase-structure grammar (Section Express- 
/ons/Funct/on Ca/), the rule 
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Arguments 

-> NamecljDarameter_association: 

Unnamed_arguments; (E \ ')♦♦ 

Named_arguments: ('<IDENTIFIER>' '=>' E) list *, •; 

Vonstraints 

As in Section Expressions/Function Call, let F be the type 
of the function being called. F must be one of the two forms 
(see Section Concept^-. 

(b) (Ti....Tn) ->T \ 

(c) (Ti,...Tn)p ->T / for LTi,...Tn types, n 2D. 

Furthermore, in the declaration of the type F, all parameter 
names must be provided. 

These requirements exclude functions declared as in "int 
f();" and "void h(int i, float);" from being called using 
named parameter association. 

The <IDENTIFIER>s in Named^arguments must collectively be 
the names of distinct parameters whose values are not suppli- 
ed positional ly. Values for all parameters must be supplied 
through either the Unnamed_arguments (positional ly) or the 
Named_argufnents. 

Given these constraints, it is possible to transform the 
function call Into a purely positional form. Further Con- 
straints and Semantics are then as if the Arguments were thus 
transformed. 

Semantics 

Since the Constraints detail how named parameter associ- 
ation can be transformed into positional form, the Semantics 
here are the same as the Semantics of the transformed call 
discussed In Section Expressions. 
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A.5 Nested Functions and Full -Function Variables 

[Pascal; function parent and environnent; up-level addressing; static 
link; display; function address versus full-function value; "!"] 

In High C, functions nnay be defined within functions. Such' 
functions are called nested. This facility endows High C with 
an expressive power that is found in Pascal. 

In the body of a nested function K any name in a containing 
scope may be used. That is, the body of N may use names local 
to other functions that contain N. This is called up- level 
referencing ^T\^ any such names are said to be up- level refer- 
encedirom N. The single restriction is that register-class 
variables may not be up- level referenced. 

Up- level referencing may be achieved by making available 
to N, at each call to it, a way to reference the collection of 
locals of each of Its enclosing functions. This reference meth- 
od is called N's environment. The function P immediately 
enclosing N Is called N's parent the next enclosing function G 
its grandparent' and so on. The collection of locals of each, 
function Is called its stack frame. 

(Technical note: N*s environment may be Implemented by 
passing to N, at each call to it, a "hidden" parameter that is a 
reference to P's stack frame. If this is done for all functions, 
P will have in its stack frame a similar hidden parameter that 
links it to G, and so on out to the global level where functions 
need no such link. This is called the static ///?/' method of 
implementing up- level referencing, the method of choice for 
best efficiency and optimization possibilities, as opposed to 
the displayrr\eXy\o6, which is not described here.) 

Therefore, a maior difference between nested functions and 
non-nested functions is that the address of a nested function N 
does not entirely capture N's "value": the environment is also 
required. In contrast, the address of a non-nested or global 
function G entirely captures its value, since G has no parent 
and thus needs no environment. The C notion of "pointer to 
function" is therefore sufficient to capture the value of G but 
not that of N. 
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Hence High C disallows taking the address of a nested func- 
tion, and, where C assunnes & before any expression of type 
function. High C does not assume the & if the expression is of a 
nested-function type. 

Full-function values. We refer to the connbination of a 
function address and its environnnent as a full-function value, 
as opposed to just a "function address". 

All of the capabilities associated with global functions, 
such as passing them as paranneters and storing their value into 
variables, is available for nested functions, although new 
syntax is required. 

A variable capable of holding a full-function value, and 
therefore the value of a nested function, is declared as a 
function declaration would be, except that "!" follows the 
parenthesized formal parameter list. Example: 

int ffv()!; 

In contrast, a standard C variable capable of holding only a 
function address is declared using the pointer syntax: 

int (*fa)(); 

ffv may be called with the expression "ffv();", but not 
with "(♦^ffvX)", since ffv is not Oust) a pointer. 

Any nested function may be assigned to ffv. A global 
function Q may be assigned to ffv by dereferencing it s\r\z^ of 
course G is transformed to 8.G by the compiler and must be 
dereferenced to obtain the full -function value of G, not just its 
address: "ffv = *^; ". The environment stored in ffv in such an 
assignment is meaningless, since 6 needs no environment. 
Upon calling the value in ffv, the environment is passed to G, 
but G (indeed every global function) safely ignores it. 

Nested functions may be passed as parameters: the full 
value is passed. The full-function value of a global function 
may be passed by dereferencing the global function: the passed 
environment is meaningless. 
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An argument can be declared as being a full-function value 
by using the new syntax: 

int f(ffv) int ffv()!; { ... ffv(); ...} 

Only the names of function constants nnay be dereferenced 
to produce full -function values. The dereference of a pointer 
to a function is innmedlately converted back to an address by 
standard C rules for function expression conversion. Thus: 

extern int sub(); 

main () { 

int (**fa)(); 

int NestedO {. . . } 

main(*main); /• Passes the full value of nain. •/ 

main(*sub); /• Passes the full value of sub. •/ 

main(**fa); /* Passes fa, since -fa => B*fa = fa. V 

main (Nested); /" Passes the full value of Nested. "/ 

} 

This extension is connpatible v\^ith ANSI standard C since 
the dereference of an expression of type polnter-to-functlon Is 
pernnitted only In the context of an expression denoting L 
function to be called, e.g. "(**fa)()"; but "(*^a)(*fa)" Is 
illegal in ANSI C. 

Example: As an exannple of the use of full -function values^ 
we present a call to a sort function that takes as parame- 
ters two functions: 

extern void Ouick_sort( 

int Lo, int Hi, int Compare(int a, int b), 
void SwapCint a, int b) 

); 
static Sort_private_table() { 
Entry Entries[100]; 
int Compare(int a. int b) { 

return Entries[a] < Entries[b]; 

} 
void Swap(int a, int b) { 
Entry Temp = EntriGs[a]; 
Entries[a] = Entries[b]; Entries[b] = Temp; 

} 
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Quick_sort(1, 100. Compare, Swap); 
} 

\-]ere it is necessary for Compare and Swap to be local to 
Sort_private_table since the table Entries Is local to that 
function. In standard C^ Entries, Compare, and Swap would 
have be nnoved outside of Sortj3rivate_table. This works 
fine in this simple case, but if Sort_private_table were 
recursive, one would have to explicitly nnanage a stack of 
Entries arrays to get the desired effect. 

Although this example may seem contrived, a stripped- 
down version of a practical Pascal program, translated into 
High C, is included in distributions of High C compilers. 
The name of the file is "analyze. c" and It implements a 
graph traversal algorithm. Any C programmer that thinks 
standard-C function capabilities are adequate should read 
this program and attempt to translate it to standard C. 

Casting any full -function value of one type to any full- 
^unctlon value of another type Is permitted. In concert with 
the ability to cast function addresses In standard C. The 
sizeof a full -function type may be taken and is always greater 
than the sizeof a function address, since the former includes 
the environment. 

The additional syntax required to permit the declaration of 
full -function types follows, and is simply a repeat of the rules 
for standard function syntax except that " ! " is allowed: 

Declarator* 

- > Extended_f unction_specif ication_declarator : 

Declarator' Parameters '!*; 
Abstract_declarator ' 

-> Abstract_declarator'? Abstract jDarameters '!'; 
Declarator2' 
-> DeclaratorZ' Parameters '!'; 



V. 11.01.85 © 1984-85 HetaWare Incorporated 



Appendix Language Extensions page A-12 

A.6 Communication with Other Languages 

[pragnas CallinjLConvention. Data. Code] 

A High C module can communicate with modules written 
in other languages partially by virtue of the pragmas Calling_ 
convention. Data, and Code. Although the syntax of these prag- 
mas is machine Independent, their effects are sometimes ma- 
chine dependent, and hence their documentation can be found in 
the Programmer's Guide, Section Externals. 



f\.l Intrinsics 

[_abs, _iiin, jm; Jind.diir. _$kip_char, _fill_d»«; jmt. jmtji^X, ^conpare] 

High C contains a set of so-called "intrinsic functions" 
that supply: (a) the ability to take the absolute value, mini- 
mum, and maximum of values of any arithmetic type, and (b) 
the ability to move and compare bytes of memory using the 
host machine's most efficient instructions. Intrinsic functions 
need not be declared to be used. Below is a list of the intrinsic 
functions followed by their descriptions In the same order as 
the list. 

_abs jnax _min 

_find_char _skip_char 
_move _move_right 
_fill_char ^compare 

_abs(x) 

X must be of an arithmetic type. The result is the absolute 
value of X, of the same type as the type of x. 

_max(e1, e2, . . . ) 
_inin(e1, e2, . . . ) 

el,e2,... must be of arithmetic types. The result is the 
maximum/minimum of e1,e2,... . 
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More precisely. _max(e1, e2) is of type T = Common(type 
of el, type of e2) and is the maximum value of e1 and e2, each 
casted to type T. _max(e1, e2,..v en), where n > 3js (recursive- 
ly) defined to be_max(_max(e1, e2), G3,..^en). The specification 
)s s i m i I ar f or __min. Example: 

float f; unsigned long ul; int i; 

main () { 

_min(f, uLi); /* Has type Float. V 

_min(ul, i); /* Has type Unsigned-Long-Int. V 

_min(i, f); /* Has type Float. *♦/ 

> 

It Is guaranteed that the operands of _max and _min are 
evaluated at most once, unlike the standard macro definition 
of max (min), e.g. "fdefine max(x,y) ((x)>(y)?(x): (y))", 
v^here one argument is evaluated once and the other twice. 

unsigned 
_find_char(any_pointer p, 

unsigned search_length, char search_ohar) 

Searches ((char*)p)[0] through ((char*)p)[search_length 
-1] for search_char using the most efficient host instruction 
to do so. It returns the index i (a number in the range 0. . 
search_length-l) if It found the character, where p[i] = 
search_char; otherwise it returns search_length, indicating a 
failed search. 

The standard function strlen can be implemented using 
_find_char: 

fdefine strlen(s) _find_char(s,65_535, 0) 

assuming at most 65,535 characters in a string. This version 
of strlen generates in-line code. 
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unsigned 
_skip_char(any_jpointer p, 

unsigned search_length, char search_char) 

Does the same as _find_char, except that It searches foi 
the first character /?otequa\ to search_char. 



void 

_fill__char(any_pointer p, unsigned len, char fill) 

Fills nnennory fronn ((char*)p)[0] to ((char**)p)[len-1] 
with the fill character. This can be used to Innplennent the 
standard library function memset: 

idef ine memset (p, fill, len) _f ill_char (p, len, fill) 

void 

_move(anyjf)ointer front any_pointer to, unsigned len) 

Moves len bytes fronn the address ((char**) from) to the 
address ((char*)to). The move occurs from left-to-righ^^ 
(lovy/er-to-higher addresses). If from < to < from+len, use 
_move_right below. 

This can be used to implement the standard library function 
memcpy: 

tdefine memcpy (dest, src, len) _move(src, dest, len) 

void 
_inove_right 

(any_pointer front any_pointer to, unsigned len) 

Does the same as _move except the move occurs from 
right- to- left (higher- to- lower addresses). If to < from < 
to+len, use _move above. 
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int 

_compare(any_pointer pi, any_pointer p2, unsigned len) 

Compares the string ((char**)p1)[0]. . ((char*) p1)[len-1] 
*yith the string ((char**)p2)[0]. . ((char**)p2)[len-1]. It 
-^^turns if they are identical, -1 if the first byte at which the 
two disagree is less in the first string than the corresponding 
byte in the other streann, and +1 otherwise. 



A.8 Brief Tutorial on Prototypes 

[arounent uidenino and shortenino; function call reliability] 

X3J11 provides an alternate fornn for specifying the 
parameter types in function declarations. When functions 
declared In this form are called, the types of the arguments 
must be assignment compatible with the types of the formal 
parameters, and as in assignment, any necessary conversion to 
the formal parameter type is applied. 

In contrast, KR specifies that the types of the declared 
parameters (if available) are irrelevant at the function call, 
and instead that default conversions are required: chars are 
widened to ints and floats to doubles. But this can lead to 
incorrect and unpredictable results when the type of the value 
passed is not compatible with the declared type; e.g.: 

float Min(f1,f2) float f1,f2; { 

return f 1 < f2 ? f1 : f2; 

} 
int i; float f, fmin; 
fmin = Min(i, f); 

Here an int i Is passed to Min instead of a double. In 
addition if sizeof (int) != sizeof (double), the f2 parameter 
to Min will not be passed in the correct location on the stack. 
(Recall that doubles are always passed as parameters in KR, 
never floats.) 

In "prototype" syntax the specification of a parameter 
name and its type are not separated and appear more like a 
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standard C declaration. The paranneter declarations are sep- 
arated by connmas, just as in standard paranneter I ists: 

float Min(floot f1, float f2) { 
return f 1 < f2 ? f1 : f2; 

> 
int i; float f, fmin; 
fmin = Min(i, f); 

With the prototype syntax, two things happen: First, float 
values are passed, not doubles. This avoids the expensive 
widening-at-call and shortening-at-function-entry cost of KR. 
Second, the int i is converted to float before it is passed, 
just as if i were being assigned to a float variable. 

Notice the repetition of float in the paranneter list: no 
factoring of declarations is permitted, as in "float f1, f2;" 
due to syntactic constraints. 

A prototype declaration nnay be used anywhere a standard 
declaration is allowed. In addition the paranneter nannes nnay 
be onnitted in declarations that are not definitions; e.g.: 

float Min(float, float); 

Prototype functionality is new, designed to allow sonne 
type -checking across separate connpilation units. For more 
information, see Sections Expressions/Function CalL Declar- 
ations/Function Definitions, and Concepts. 
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Appendix B 
Collected Grammar Rules 



The grammar rules used in the various sections are 
collected here for easy reference. 

Phrase-Structure Grammar 

Miser Cj)hrase.structure, C.conditional.conpilationjexpression: 

Cjihrase structure * The above is for the preprocessor. 
-> Externaljdeclaration* 

# Declarations. # 

Extemal.declaration 

-> Unspecified declaration: 

( Function definition i Non function definitions ';' ) 
-> Specified Seclaration « With specifiers. 

-> Pragna call 
-> ';' ~ # Syntactic oddity of KR. 

Pragna call 

-> ViflM' Nane (•(' (E lift '/)? •)•)? 

Specified declaration 

-> Specifiers ';' 

-> Specifiers Function definition 

-> Specifiers Monjunclion.definitions ';' 

# Types and Specifiers. ft 

Specifiers 

"> Type_or_storage_classes 

type or.storage classes 

-> Storage.class Type or storage classes? 

-> Typedef reference: "^<T?PEOEF li»1E>' Storage class? 

-> Type ASCs 

-> Adjective ASCs (Type ASCs)? 

ASCs 

-> (Adjective I Storage.class)** 
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Stor«g(_class 

-> 'auto* I 'extern' I 'reflistcr' I 'typedef I 'static 

Adjective 

-> 'srwrt* I 'unsioncd* I 'long' I * signed* 

Type specifiers 

-> Typedef reference: '<TYPEOEF.HA«E>* 

-> Adjective- Type Adjective- 

-> Adjective* 

Type 

-> 'cMi* I 'inf I 'float' I 'double* I 'void' 

-> Tagocd.type 



page B-2 



Tagged.type 








-> Cofiplete.definition: 


'struct' 


Tag? ' 


V MefiPer list ' 


-> Co«pletc_dcfinition: 


'union' 


Tag? ' 


{' McADer.list ' 


-> Complete definition: 


'enu«' 


Tag? • 


{' Literal.list ' 


-> Use.orjnconpletc.dcfinition: ( 
-> Reference: 


'struct' 


Tag 




'union' 


Tag 




'enun' 


Tag 





Tag 

-> Tag: Kane 

Literal list 

-> (Haw ('=' Constant: E)?) list ',' '/? 

fjenber.list 

-> Also_is_a_list: Henbers list ';' ';'? 

nenbers 

-> Type_spccificrs (StructUTc_«e«bcr list ',')? 



Suucturc Hcrt)cr 

-> Declarator 

-> Field.nenDer: Declarator? 



Bits: Constant: E 



*•****>»*■**** ^*»U Ufc* *J *» A* ***■**■» ** *a **■■ — *« J* »^A« J lJj Aa* jA<J« *J ** l*^ ■« — ■* A*** M 4a ■>»** ■ it i » tt*jl>l«l« 11 At !■ *»»>■>>* mi <■■» 1 ■ 

■^•FW^if MM UMM •III •f*rTwwWFWWw*rW»CW^'CWT*^fr*C»^W*rTW •••■•• *V<| im IVII if M M N M >V N^ M ■! ■! VIM ■■ ■ l«ffWI r^fr 

// Declarators. ft 

Declarator 

-> ••' Declarator 

-> Declarator' 

Declarator • 

-> Declarator* '[' Array.specification *]' 

-> *(' Declarator *)* 

-> Function_specific8tion: 

Declarator' *(' Para»wters ')' 
-> Declared: Ka«e 
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Array.spccification 
-> Constant: E? 

Parameters 

-> Parawter.na«es «ly: Para«eter_na«e list */ t1orej)ar«s? 

-> Abstracuarawters 

AbstractjMraMters 

-> (SO list •/ Horej>ar«s?)? 

-> specifiers (ADstract^deciarator I oeclarator2)? 

Horej>arRS 
-> •/ •...'? 

Paramter nane 
-> •<IOEMTIFIER>' 

Abstractjdeclarator 

-> '"' Aostractjieclarator? 

-> f«)stract_declarator' 

Abstract^declarator ' 

-> W»tracl.declarator'? '[' Array.specification ']' 

-> Function^specification: 

Abstractldcclarator'? '(' Abstractjwrancters ')' 
-> •(• ftbstract.declarator ')' 

k Declarator2(') needed to avoid an ambiguity. 

Declarator2 

-> ••' Declarator2 

-> Declarator2' 

Declarator2* 

-> oeciarator2' *[* Anay..specification •]* 

-> Function_specification: 



_specifi( 
Oeclarator2' '(' Parameters ')' 
-> •(• 0eclarator2 *)' 
-> Oeclaredjw«e:'<10EIITIFIEB>' 



« Definitions. # 

Hon function.definitions 

-> Tocclarator C-' Initializer)?) list ',' 

Initializer 

-> E 

-> •{• Initializer list '/ '/? *>• 

Function.definition 

~> Fen: Declarator Parafwter.types Conpound.statemnt 
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Paramter types 

-> (Specifiers (Parmeter: Declarator list '/)? ';')• 

« Statements. « 

Conpound statenent 

-> '<• Tspecifiedjdeclaration I Pragna.call I Statenent)* '}' 

Statenent 

-> Conpound.statenent 

-> EL •;' 

# Switch and its cases: 
-> 'switch* •(• EL •>• Switch Jwdy: Statement 
-> 'case' Case^abel: t New fron X3J11: 
Constant: E (' . . ' Constant: E)? 
':' Statement 
-> 'default* ':' Statement 

« End of switch and its cases. 
-> 'if '(' EL •)' Statement ('else' Statement)? 
-> 'while* *(' EL ')' Statement 
-> *do' Statement 'while* *(' EL *)* *;* 
-> *for* '('First: EL? ';' MextEL? *;* Last:EL? *)* 

6ody: Statement 
-> *break* 
-> 'continue* 
-> 'return' EL? 

-> 'goto' Targel_lat)el:Name ';' 
-> Labelled statement: 

Label: Name ':* Statement 
-> *;• 

# Expressions. # 

C.conditional.compilation_expression-> E2; « For the preprocessor. 

DEL -> EL?; « Optional Expression List. 

EL -> E -> E */ EL; # Equivalent to: E list *.*. 
E -> El; * Two columns for compactness. 

El -> E2 -> Lvalue: Term* Plain.assignment: *** El 

-> Lvalue: Term' (Assignmenijoperator El); 

Assignment^operator 

-> '\x> |>*.' I '6=' I •»=• I •«=* 
I •♦=• I •-=• I •-=• •/«• I •%='; 

-> Conditional expression: 
E3 *?• EL ^: ' E2; 

->E3'||*E4; 

-> E4 '66' E5; 

-> E5 *T* E6; 

-> E6 * * E7; 

-> E7 *6* E8; 

-> te •==• E9 

-> EB '!=• E9; 
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E2 -> E3 



E3 


-> E4 


E4 


-> E5 


E5 


-> E6 


E6 


-> E7 


E7 


-> E8 


EO 


-> E9 
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E9 -> E10 -> E9 '<• E10 
-> E9 •>' E10 
-> E9 '<=• E10 
-> E9 •>=• E10 

E10 -> Ell -> E10 '»'E11 
-> E10 '«'tU 

Ell -> E12 -> Ell •♦• E12 
-> Ell '-• E12 

E12 -> E13 -> E12 ••• E13 
-> E12 V E13 
-> E12 •%• E13 

E13 -> Tern 

tern 

-> Tern* 

-> •(' Cast^type ')' Tern 



Tern' 



-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> 
-> T1 



Pointer: Tern 
6' Tern 
-• TerR 
♦• Tern 
- Tern 
r Tern 
•' Tern 

sizcof (•(• Ca8t_type ')' I TerR') 
♦♦' Lvalue: TerR 
— ' Lvalue: TerR 



T1 

-> Lvalue: T1 '♦♦' 

-> Lvalue: T1 '— ' 

-> T1 •(• ArouRents ')• 

ArguRents 

-> (E list •/)? 

tl 

-> Tl •[' EL •]• 

-> Tl '->• lleflber:NaRe 

-> PriRary 

-> Tl '.' neRber:Nane 

hrlRary 

-> •(• EL •)• 

-> MaRe:'<lOEMTIFIER>' 

-> Constant 

Constant 

-> XIMTEQER)' I •<FLOAT>' | •<CHAR>' | '<OCTAL>' | •<HEX>'; 

-> XSTRINO** Cast type 
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Nam 

-> •<IDENTIFHR>' | •<TYPEDEFJ*A«E>' 

end Cj)hrase_structure 



Preprocessor 
Phrase-Structure Grammar 

parser Cj)reprocessor_text: 

Cj)reprocessor text 

-> (Conuol.text I yord)- 



Uord -> Any - '<CONTROL>' - '<C-EOL>' « Any word fron the lexical 

# analyzer except these tuo. 

Words -> Uord* 

Control text 

-> ^CORTROU'! 'include' •«$TRIMG»' '<C-EOL>' 
-> •<C0HTROL>'! 'include* 'KSTRIMG)' •<C-E0L>' 
-> •<COHTROL>'!'cJnclUde' '<$TRIII8>' •<C-EOL>' 
-> 'kCONTROD'I 'define' 

( Macro jwne: '<II0 J>ARI1S>' 

f Nacro nane: '<UlTHJ>ARn$>' 
•(' rParaneter:'<IOENTIFIER>' list ',' )? ')' 

) BodyrMords •<C-EOL>' 
-> •<COIITROL>'!'undef' Macro na«e:'<IOENTIFIER>' •<C-EOL>' 
-> < '<COHTROL>'!'if' E '<C-EOL>' IfiUordS 

f '<COIITROL>'!'ifdef' •<IDEMTIFIER>' •<C-EOL>' Words 

I '<COMTROL>'!'ifndef' '<IDEMTIFIER>' '<C-EOL>' Words 

('<COMTROL>'!'elif' E •<C-EOL>' Elif:Words)« 
('<CONTROL>'!'else' '<C-EOL>' Else:Words)? 
•<CONTROL>' ! 'endif •<C-EOL>' 



E -> C_conditional_conpilation_expTession; # See the High C PSG. 

// The E nonterninal generates the sane language as E2 in the C phrase- 
i\ structure grannar (PSG: see Section fxpressions w\(S below), except that 
// Prinary is extended with the following two additional alternatives: 

# -> 'defined' Hacro_nane: '<IDENTIFIER>' 

// -> 'defined' '(' Macro.nane: '<IDENTIFIER>' ')' 

end Cj)reprocessor.text 



V. 1 1 . 01 . 05 © 19B4-B5 HetaUare Incorporated 



High C Collected Grammar Rules 



page B-7 



Lexical Grammar 



scanner C.lexicon: 



C_Jexicon - 
Text 



Words - 
Word 

Identifier- 
Id text - 
Letter - 

Nunber 
Integer - 
Octal 
Hex 
Float 

Mantissa- 



scanner Dot dot: Dot dot ->'.'•.'"; end Oot_dot 



Exponcnt- 



Float_su?i 

Hiflits - 

Higit - 

Digits - 

Digit - 

Digits - 

Digit - 

String 

Char 
DQchar - 
SQchar - 
Special - 



Operator - 
OtherOp - 



Text; 

(Words Line.end)* (Controljine Text)? 

NScanning Siapped.lines ControlJLine Text; 

Word-; 

String i Char I Nunber I Identifier 

Deliniter I Punctuator I Operator I Coment; 

Id text 

Letter (Letter I Digit)-; 

'A'.. 7' I 'a'.. '2' I V ; 

Integer I Octal I Float t Hex ; 
'V.rr (• '? Digits)? Integral^suf fix? 
'0* (' '? OTgits)? Integral.suffix? 
'0' I'T I 'x') Higits Integral_suffix?. 
Hantissa Exponent? Float.suff ix? 
Digits Exponent Float suffix? 
• ^ Digits I Digits \Dot 3bt *. * Digits?; 



'L* 
•f 

t _ 
#_ 



rE'l'e')!**'!'-')? Digits; 



Integral suffix -> 'u* '1'? 



ix 



•1* 'u*? 
'1' 



I •a'..'f 



-> 'L' 
Higit* list ' '; 

Digit* list '_•; 
•or. '9' ; 
Digit* list •^•; 
'0\.'7' ; 



DQchar- '- 

SOchar "" 
Any-'\'-"" I '\' Special ; 
Any-'S'-"" I '\* Special ; 
'a* I 'b* I 'f I 'n' I 'r* 
•N* I - •••• 
Digit (Digit Digit?)? 
•x^ Higit (Higit Higit?)?; 

AssignOp | OtherOp; 



nil il > 



'U 
•F* 



L'? 



• Ml 

• III 



I 'f I 'V 



'<• '=• 



•r •! 

I • • I 



•>' 
'<• 



• • • %. I 



« Operators that can be followed by '-' in assignnents. 
AssignOp-><"*' I •>• •>• I •<' •<• 

•*• •-• 'Z' I •%• 

... I ./. I .|. 

) •=■? 



=>'<IDEMTIFIER>'; 



=>'<IHTEGER>'; 

*>'<OCTAL>'; 

=>'<HEX>'; 

»>'<FLOAT>' 

->*<FLOAT>'; 



•U'?; 

is non-standard, 
is non-standard, 
is non-standard. 

=>'<STRIMG>'; 
=>'<CHAR>'; 



« Octal. 

« Hexadecinal. 



•>'<ASJS>'; 



=>'<ASJS>'; 
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Punctuator-> '(' I ')' I ';• I '.' '.' 

IiriliSiiiiiiii lit 

Ocliniter -> ( Space: ' '♦ I HorizTab: 'hf 
I FomFced: 'ff j Vert: Tab: 'vf 
)♦ 

Cofwent -> V '•• Rest 
Rest -> hosf •••♦ (V I («ost-V) Rest); 
host -> Any-'-' I Eol; 



page B-8 

=>'<ASJS>'; 

«>"<OELETE>*; 
«>'<DELETE>'; 



t Preprocessor lexicon: 



Line_end 

Control.line 
Sharp 
Control 



Done 



-> Eol 

-> StMurp Deliniter? Control? Linejend; 
-> •#' 

.word Define Deliniter Hacro 
.text else other.controi) 



-> ( /Define won 
J (include.te! 
) iiords Done; 



-> 



Qther.control -> Id_text 
Macro -> Id^text \LP 
-> ld..text /LP 

scanned LP: LP -> '(' ; end LP 
scanner Define.word: 
Define word -> 'd* 'e' 'f 'i* 'n* 'e*; 
end wfinejford 
Define -> Definejiord 

scanner Include.text: 
Include.text-> IncludejMid Deliniter? Funny^tring; 
Include word-> 'i' *n' 'C '1' 'u' 'd' 'e' 
Funny string-> L angle File nane R.angle; 
L.angle -> '<' 
R angle -> '>' 

Filejwnc -> (Any-'\'-""-'>' I '\' Special)- 
end Include.text 

Skipped.lines -> (\Sharp Skipped line)-; 
scanner Sharp: Sharp -> '«'; end Sharp 

Skipped l^ne -> Skip suffix? Linejend; 

Skip_suTfix -> ( Noopecial J Slash I Coment 

Mot.special -> (Any - •/'-"")♦ 

Slash -> V 

DString -> StringLtext 



«>'<DELETE>'; 



«>'<OELETE>'; 



=>'<C-EQL>' ; 
s>'<COIiTROL>'; 
«>'<IIO PAR«S>• 
->•<^IITHJ»ARMS>•; 



=>•<COIITROL>•; 



=>'<COIiTROL>'; 

«>'<OELETE>'; 
■>'<OELETE>'; 
=>'«STRIM8»'; 



DStling )-; 

=>'<DELETE>'; 
»>*<DELETE>'; 
->'<DELETE>'; 



end C^exicon 

reserve *<IDENTIFIER>' « Uould-be ids used as key words in the PSG. 



predefined Scanning 
« Eol 



» External feedback fron the preprocessor. 
« Predefined in graiwiar notauon: end-of-line. 
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Appendix C 

High C '^ 

Phrase-Structure Chart 

The chart below was produced by the MetaWare Translator 
Writing System (TWS) fronn the grammar that also produces 
tables by which the High C compiler parses its programs. A 
few of the diagrams in the chart have been touched up by hand 
for increased efficiency of space usage. The interested reader 
should see the MetaWare TWS User's Manual. 

To "read" the syntax diagrams of which the chart is 
composed just follow the "railroad tracks" to find out what 
words may be written in what order. Start at the upper left 
corner and go only with the arrows. Eventually you will be able 
to escape the tracks to the rights in which case a syntactically 
correct phrase will have been formed. 

To form an entire program, start with the first phrase 
name diagrammed, namely High_Cj)hrase_struoture. When 
another such name is encountered you must follow the tracks 
in Its diagram and then return to the current tracks just after 
the phrase name that caused your departure. When a basic 
symbol is encountered, just write down the symbol. 

The result of your tracks visitations and the writing down 
of the basic symbols will be a grammatically correct High C 
program. To find out how to form words correctly from Indi- 
vidual characters see the "lexical chart" in the next appendix. 

Here symbols like <ioemtifier> refer to the symbols des- 
cribed by the lexical chart; their names are usually self- 
explanatory, but when in doubt consult the following appendix. 

The italicized ^QT^ in these charts are purely commen- 
tary. Their removal would not change the language described 
by the chart. For example. Constants (E for Expression) is 
equivalent to just E, but the intent is to inform the reader that 
in the current context the Expression must be constant. 
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High_C_j)hrose_structure - 



i 



'<- External_declarotion 4-" 



External_declaration = 

UnspecifiecLdeclaration: 

J->?-> Function definition ^"-^ 

{■-> Non function_definitions ; -4» 
?-> Specified declaration ■■' ) ■ 
T*^ Pragma_call .» ■ 



.i 



Pragma_call = /* Direct the compiler. V 

•-> pragma Name -»?■■ ) ■*■> ; -^ 

w 



»-> ( -> 



V Constant: 
— > E 



t^.. 






Specif ied_declaration « 

?-> Specifiers ; >■-> 

t^ Specifiers Function_definition »* 

' ... .* 

■-> Specifiers Non_function_definitions ; ->• 
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Specifiers « 
Type__or_storage_classes = 
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■-> StoraQe^class — >• 

I V 

I ■-> Type_or_storaoe classes - 

I 

V Typedef^reference: 

■-> <TYPEDEF_NAME> ->• 

I V 



'-> Storage_olass 



• >._> Type /^s 

V A 

■-> Adjective ASCs ->• 



'-> 



ASCs = 

. >.-> 

A V 

■<- Adjective < • 

A V 

■<- Storage.class <-• 



Storage_class « 

■-> auto >•-> 

V A 
•-> extern — ^>" 

V A 
■-> register ->" 

V A 
■-> typedef — >■ 

V A 
■-> static — >• 



Adjective ■ 

•-> short >•-> 

V A 
•-> unsigned ->■ 

V A 
•-> long >■ 

V A 
•-> signed — >■ 
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Type_specif iers ■ 
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'-> rypec/eCrefererfce <VfPEDEF_miE> 






>-_> Jypg _>. >• — >• 

V A V A 

<- Adjective <-■ •<- Adjective <-■ | 



Type - 

-> char — >■ — >•-> 
V A A 
-> int >■ 

A 
-> float — >• 

A 
-> double ->• 

A 
-> void — >• 

-> Tagged_type ->■ 
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Tagged_type - 

Complete^ definition: 

•-> struct ->•->• >■-> { Member list } — >•-> 

I A V A t 

•-> union -->• ■-> Td'^Nome ->• I 

V I 

■-> enuM >■ >•-> { Literal list } ->• 

I V A " A 

I •-> r^Name ->• I 

I I 

I Use__or_incotnplete__ctefinition: \ 

V I 
■-> struct ->• > TJ^Name >• 

V A A 
■-> union — >• I 

I I 

I Reference: I 

V I 

■-> enun > 7^l!^Name >■ 



Literal__list « 

■-> Name ->■ >■->■ >■-> 

A V A I A 

I ■-> = Constants ->■ | | 

I V I 

.< ^ < ._> ^ _>. 



Member_list ■ 

•-> A2so_is_a_Iist Members >• >•-> 

A V A 

.< , < ._^ . _^. 
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Members >« 

•-> Type_specifiers ->• 

V 
-< . 

V 

. >._> 

V t 

• ->•-> Declarator >■->• 

t \J t \ 

I . >._> . ^jY5 Constant E ->■ | 

I V FielcLmember t I 

I ■-> Declarator — >■ I 

I V 

.< . ^ < . 

Declarator = 

•-> ** Declarator >■-> 

V t 
■-> Declarator* >■ 



Declarator' « 

•-> Declarator* [ Array_specification ] ->■-> 

V t 
•-> ( Declarator > >• 

I A 

V Function^specification: I 
■-> Declarator* ( Parameters ) — >■ >• 

V A 
■-> Declared Wm^ >■ 



Array__specification 

. — >. 

V A 

■-> Constant E ->■ 
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Parameters - 

Par&neter_nomes_only: 

— >■-> <IDENTIFIER> ->•—>•->• >•-> 

I A V A V A 

I •< , < • I •-> , ->• >• 

V I V A 

"-> Abstract jjarameters ->• ■-> ... ->• 



Abstractj)arameters - 

. >._> 

V A 

■-> SO ->■ >• 

A V A 

-<- , <— •-> , ->• >• 

V A 

--> ... ->- 

SO 

-> Specifiers ->• >•-> 

V A 
•-> Abstract_declarator ->• 

V A 
■-> Declarator2 >■ 



Abstract_declarator = 

.-> » ->. >..^ 

I V A 

I ■-> Abstract_declarator ->■ 
V A 

■-> Abstract declarator' >■ 
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Abstract_declarator' - 

•-> Abstract_declarator • ->■ 

I V 
I .< 

V V 

■-->■-> [ Array specification ] ->■-> 
I I ~ A 

I V Function^specification: \ 
I ■-> ( Abstract_paraineters ) ->■ 

V A 
•-> ( Abstract_declarator ) >• 



Declarator2 « # Next two needed to eliminate 

# an ambiguity. 

•-> ** Declarator2 >•-> 

V A 

■-> Declarator2* >■ 



Declarator2' > 

■-> Declarator2' [ Array specification ] ->■-> 
I A 

V Function_specification: I 
•-> Declarator2' ( Parameters ) >• 

V A 
■-> ( Declarator2 ) >• 

V A 
— > Declared ffooie <IDENTIFIER> >• 



Non_f unction__def initions » 

■-> Declarator ->■ >•->■-> 

A V A I 

I ■-> = Initializer ->■ | 

I V 

.< ^ <_ . 
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Initializer - 

._> E >•-> 

V A 

•-> { ->•-> Initializer ->■ >•-> } ->■ 

t V A 

.< ^ < .-> ^ ->. 



Function_clef inition = 

•-> r^ Declarator Parameter.types Conf)Ound_statefnent -> 

Parameter_types ■ 

. >--> 

V A 

•"> Specifiers ->•< •-> ; ->• 

A V A i 

I ■-> Af/vaweffiT Declarator ->• I 

I A VI 
I .< ^ < I 

I V 

.< . 

Compound_statenient » 

■-> { ->• >•-> } -> 

V A 

■->•-> Specified_cleclaration ->■->• 

A V A I 

I ■-> Pragma^call >• j 

IV A I 

I •-> Statement >■ j 

I V 

.< . 
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Statement « 

•-> Compound^statement >■-> 

V A 
-> EL ; >. 

V A 
■-> svitch ( EL ) 5'«zYcyt./wfl^ Statement >■ 

V A 

•-> case Constant E ->•-> . . Constant E ->• | 

i V VI 

I .< . I 

! ^ ' 

I ■-> : Statement >■ 

V A 
•-> default : Statement >■ 

V A 
•-> if ( EL ) Statement ->■ >• 

I V A 

I •-> else Statement ->• 

V A 
■-> while ( EL ) Statement >• 

V A 

•-> do Statement while ( EL ) ; >■ 

I A 

V First Next Last Body I 
•-> for ( OEL ; OEL ; C€L ) Statement -->• 

V A 
■-> break ; >• 

V A 
•-> continue ; >■ 

V A 
■-> return C€L ; -— >■ 

V A 
•-> goto Target_label Name ; >■ 

V A 
■-> LadellecLstatement Label Name : Statement ->■ 

V A 
.-> . >. 



V. 11 . 01 . 85 © 1984-B5 HetaUare Incorporated 



High C - Phrase-Structure Chart 



page C-11 



OEL - 

•-> E ->■-> 

V 6 
. >. 

EL - 

•-> E , EL ->•-> 

V t 
— > E >• 



/*» Optional Expression List. 
/*• Used only in Statements. 



/** Equivalently: 

/* 

/*• •-> E ->•-> 

/* A V 



/* Operator precedence levels are 
/* indicated by the "subscripts" on E: 
/* larger subscripts mean more binding. 

Assignment^operdtor: 






■-> Lvalue ^^x^* -> 



•-> = — >■-> El ->■-> 

V A A 
-> 1= ->• 

V A 
.-> % ->- 

V A 
•-> &» — >■ 

V A 
•-> »« ->• 

V A 
•-> «= ->• 

V A 
•-> += — >• 

V A 
•-> -= — >• 

V A 
•-> *=» — >• 

V A 
--> /= — >- 

V A 
--> X= ->• 



/* El */ 



V Conditional_expression: 
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— > E3 ? -~ > EL > : E2 >■ 

I A 

I I 

V I 

V 



•-> E3 II E4 -> 

\i 

— > E4 && E5 -> 

V 

•-> E5 I E6 -> 

V 

-> E6 " E7 -> 

V 

•-> E7 & E8 -> 

V 

•-> E8 " E9 -> 

V 

•-> E8 !- E9 -> 

V 

•-> E9 < E10 -> 

V 

•-> E9 > E10 -> 

V 

•-> E9 <- E10 -> 

V 

•-> E9 >- E10 -> 

•-> E10 » E11 -> 

--> E10 « E11 -> 

— > Ell + E12 -> 

— > Ell - E12 -> 

— > E12 * E13 -> 

— > E12 / E13 -> 

•-> E12 % E13 -> 

■-> Term > 



/* E4 *•/ 
/* E5 V 
/* E6 */ 
/* E7 V 
/M E8 */ 

/* E9 •/ 



/* E10 V 



/*• Ell V 



/*• E12 V 
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/* E3 *•/ 



/♦* E13 V 
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Term 



•-> Term' >■-> 

V A 

•-> ( Cost_type ) Term ->■ 



Term' = 

■-> sizeof ->■-> ( Cast^type ) ->■-> 
I V ti 

I •-> Term* >■ 

V A 
•-> T1 >■ 

V A 
■-> ♦ Term >■ 

V t 
■-> - Term >• 

V 6 
•-> * Term >■ 

V t 
•-> & Term >■ 

V A 
•-> ! Term >• 

V t 
■-> ~ Term >■ 

V t 
■-> 4+ iyaJue Term >■ 

V A 
•-> — LysJue Term >■ 
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■-> Primary 

V 

•-> LvaIuel^ ♦+ 

V 

•-> Lvalue T^ 

V 

■-> T1 ( Arguments ) 

V 

•-> Tl [ ->•-> EL->--> ] - 

V 

— > Tl -> /yfewto/- Name 

V 

— > Tl . ffemberHw^ 



'-> 



Primary = 
-> ( ->■-> EL->--> ) 

-> <IMTECER> — >• 

-> <FLMT> >■ 

-> <CH^> >• 

t 
-> <OCTAL> >• 

A 
-> <HEX> >• 



->•-> <STRING> ->■■ 

I A V 

I .< . 

V 

■-> <IDEMTIFIER> 



t 
I 
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Arguments - 

. >.-> 

V S 
?->•-> E ->• >• 

i/ A V t 

•<-<- , <- I 

V I 
•-> <IOENTIFIER> -> E ->• 
A V 
■< . < 



Cast_type =« 

•-> Type_specifiers ->■ >•-> 

V A 

•-> Abstract declarator ->■ 



Name » 

•-> <IDEMTIFIER> >--> 

V A 

•-> 7ype(fef_refereftce <V<?UiUjmi> ->- 



end High_C_phrase_structure 
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Appendix D 

High C ^ Preprocessor 
Phrase-Structure Chart 



The chart below was produced by the MetaWare Translator 
Writing System (TWS) from the phrase-structure grammar of 
Section Preprocessor, also found In Appendix Collected Gram- 
mars. The large diagram was touched up by hand for Increased 
efficiency of space usage. For more information on how to 
read this chart, consult the Introductory paragraphs In Appen- 
dix High C Phrase-Structure Chart 



Cj)reprocessor_text 



•->?-> Control text <C-EOL> ->■- >• 



»■- > 



t 



■•> Word 

i 



4 



Word « /* ftny word frwi the lexical analyzer except two: *l 

— > Any except ^CONTROL)' except •<C-EX>* -> 



Words 



•»•- > 



■f- Word f~- 
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-> include <STRING> 

V 

"-> include «STRING» 

V 

--> conclude <$TRING> 



V Macro nane: Bcxfy: 

■-> define ->■-> <IIOJ>]ta«$> ->■-> Words 



■>■-> 

A 
->• 

t 
->■ 

A 

I 
•>■ 

A 



V /tKTO nme: i 

•-> <«ITHJ»<W!S> ( ->• >-> ) ->« 

V Paraneter: A 
-> <IOENTIFIER> ->■ 
A V 

•< , < • 



-> undef Hacio ime <IOEIITIFIER> 

V 

■-> if E <C-EOL> //" Herds >• 

V V 
-> ifdef ->-> <IOEMTIFIEfl> <C-EOL> Mords ->■ 

V A . V 
•-> ifndef ->• ■< ■ 

V nif: A 
-> elif E <C-EOL> yords ->■ 
V 

. >■-> endif 

V Else: A 
■-> else <C-EOL> Mords ->• 



->■ 



E » /* See the High C PS6. */ 

■-> C__conditional_conipilation_expression -> 

/• The E nonteminal generates the sane language as E2 in the C phrase- V 
/" structure grannar (PSG: see Section Expressions vA belou), except that*/ 
/* Prinary is extended uith the following two additional alternatives: «/ 

•-> defined Macro name <IDENTIFIER> >•-> 

•-> defined ( Hacro^nane <IDENTIFIER> ) ->• 

end Cj3reprocessor_text 
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Appendix E 
High C " Lexical Chart 



The chart below was produced by the MetaWare Translator 
Writing System (TWS) from the grammar that also produces 
tables by which High C compilers lexically analyze their input 
programs. A few of the diagrams in the chart have been 
touched up by hand for increased efficiency of space usage. For 
more information on how to read such charts, consult the 
introductory paragraphs of Appendix High C Phrase- Structure 
Chart 



C_lexicon - 
•-» Text -> 

Text = 



•ords Eol -^1 *-> Control line Text -^ 



•I 



V ^ ♦ 



■> Skipped_lines Control^line Text > 



Words » 



•«• 



t 



Word 
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Word - 
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■-> string 





— > 


— > 


V 

■ _\ OUat- — 




— -.\ 




~/ unor 




— / 




V 




_~— \ 




/ NLNnoer — — 




— / 




V 

■-> Identifier 




.._\ 






— / 




V 




~— \ 




/ ueiimiLer 




— / 




V 




-.~.\ 




~/ LoinnenL — 




— / 




V 

•-> Punctuator 




_-.-.\ 






— / 




V 




-—.S 




-/ uperciLor — 




/ 




Identifier « 








Id_text » 








•-> A ->•->•— 




.-- .. 


>■-> 


V .. A V 






A 


•-> Z ->• •->« 


'-> A 


_Sa — 


>• 


V AAV 


r ^ ^ 


A 




•-> a ->• 1 • 


•-> z 


.s* 




V .. A 1 \ 




A 




•-> z ->• 1 ■ 


-> a 


— Sa 




V AM 


' • • 


A 




•-> ->• 1 ' 


•-> z 


— Sa 




1 V 




A 






■-> « 


— Sa 




1 V 




A 






'-> 


— Sa 




1 \ 


' • ■ 


A 






'-> 9 


— \a 




■/-. 






V 
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Number * 

'"> Integer ->•-> 

V A 
•-> Octal — >■ 

V A 
•-> Hex >• 

V t 
— > Float — >• 



Integer = 

■-> Digit except ->■ >•->• >■-> 

■ >■-> Digits ->■ ■-> Integral_suffix ->■ 

V h 

■-> _ ->■ 



Octal « 

•-> ->■ >•->• >•-> 

V A V A 
. >.-> oigits ->• •-> Integral_suffix ->■ 

V A 
•-> ->• 



Hex = 

■-> ->•-> X ->•-> Higits ->■ >•-> 

V A V A 

■-> X ->• •-> Integral_suffix ->• 
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Integral_suff ix - 

-> 
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■ ■ 


-> u 


->• 


-> 1 




V 








A 


a. 


-> 1 


->' 


-> u 


-.\a 


V 








t 


«. 


-> U 


->• 


'-> L 


— Sa 

t 
_\a 


V 








t 


■ - 


•> L 


->' 


-> U 


-.\a 
t 



Float = 

Float^suffix: •-> F ->■-> 

L A 

■-> f ->• 

A A 

Mantissa: •-> L ->■ 

A A 

. >■-> . Digits ->■ ■-> 1 ->• 

V A V A A 

•-> Digits ->•-> . >• >•— — >• 

V V A 

. >•_> Exponent ->• 



Exponent s 

•-> E ->•->• >■-> Digits -> 

V A V A 

•-> e ->■ •-> + ->■ 

V A 

•-> - ->• 



v.11.01.85 



© 1984-85 HetaUare Incorporated 



High C Lexical Chart 



page E-5 



Digits « 

■-> Digit ->•-> 
A I 

■< • 

A V 

•< — _ < — • 

Digits = 

•-> Digit ->•-> 

A V 

.< . 

A V 

•< — _ < — • 

Higits ■ 

■-> Higit ->■-> 
A V 

•< ■ 

A V 

-< — < — • 



Digit 
V 



-> ->•-> 

.. A 
-> 7 ->• 



Digit - 

-> ->■-> 

.. A 
-> 7 ->■ 

Higit - 

-> ->•-> 
.. A 

-> 9 ->■ 
A 

-> A ->• 
.. A 

-> F ->• 
A 

-> a ->• 
.. A 

-> f ->■ 
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String « 
Strinfl_text = 

•-> " ->■ >•-> " -> 

V A 

■->•-> Any except \ except " ->•->• 

A V A I 

I ■-> \ ->■-> Octal hex ->•—>• | 

I V " A I 

I •-> Any >• I 

I V 

.< . 



Octal_hex - 

■ — > Digit ->• >•-> 

I V A 

I •-> Digit ->• >■ 

i V A 

I •-> Digit ->• 

V A 
•-> X ->•— > Higit ->■ >• 

V A V A 
•-> X ->■ •-> Higit ->• 



Char = 

■-> • ->■-> Any except \ except ' ->■-> ' -> 
V A 

■-> \ ->•-> Octal_hex ->•-->• 
V A 

■-> Any >■ 
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Operator « 

•-> AssignOp ->•-> 
V A 

•-> OtherOp — >■ 



AssignOp « 

•-> " — >•->• >— > 

V A V A 
— > > > ->• — > - ->• 

V A 
•-> < < ->• 

V A 
■-> + — >■ 

V A 
•-> *» — >• 

V A 
--> & — >■ 

V A 
— > % — >• 

V A 
•-> >• 

V A 
— > / — >■ 

V A 
— > I — >■ 
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OtherOp ■ 

..> - — 

V 
•->&&- 

-> I I - 
■->>-- 
— > < — 
— > . . - 

•-> > — 

■-> - - - 

--> - > - 
V 

V 

— > ! — 

V 

•-> . — 

V 

•-> . — 

V 

--> ? — 



'-> 
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Delimiter = 

•->•->■-> Space: ->■->■->•-> 

A I A V A 
I -< I 

V I 
•-> HorizTabiht — >■ 

V t 
■-> FormFeediff — >• 

V 6 
■-> Vert: Tab: vt — >■ 



Punctuator = 



Comment « 

■-> / * Rest -> 

Rest « 



-> ( 

V 

■-> ) 
V 
■-> ; 

V 

•-> . 

V 

•-> [ 
-> ] 

V 
V 

•-> . 

V 

-> { 

V 

->} 

V 
•-> : 



-> 



. >■->•-> * ->•->•-> / >•-> 

h V A V V 6 

•<- Most <-• •< ■ •-> Most except / Rest ->• 



Most = 



•-> Any except * ->■-> 
V L 

•-> Eol >• 
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# Preprocessor lexicon: 

Controljine « 

•-> # ->•-> Delimiter ->• 

V V 

.< .< • 

V 

. — _ >.-> Eol -> 

V A 

•-> d e f i n e Delimiter Id^text ->■-> iords ->■ 

I A 

I .< 

V A 

•-> i n c 1 u d e ->■ >■-> < File^name > ->■ 

I V t 6 

I •-> Delimiter ->• I 

V I 
■-> Id_text ->■ >• 

V L 

■~> Digit — >• 

A V 

.< . 



File^name * 

. — >•-> 

V A 

■->■-> Any except \ except " except > ->"->■ 

A V A I 

I ■-> \ ->--> Octol_hex ->• >• I 

i V A I 

I •-> Any >• I 

I V 

.< . 
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Skipped_lines 



V 



h 

■>•-> Eol ->• 

A 



■->•->■-> Any except A " ->■->■-> 

I .< . I 

V I 
•-> / >• 

V t 
•-> Comment >• 

V A 
•-> StrincLtext >■ 



end C lexicon 
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Index 

Starting on the next page is a "permuted l<ey word in 
context" index for this docunnent. In the center column is the 
particular key word W being indexed, in the context of a phrase 
or sentence containing W. The phrase appears to the left and 
right of W. 

Occasionally the text of the phrase preceding W does not 
fit in the space to the left of W. In that case the index entry 
looks like 

it ttit tkat IMS tM iMf ti fttctit tk% UOtI btiii in^txH. Tkis 7.4 

where the first word "This" of the sentence did not fit on the 
left. Similarly the text to the right of W can be crowded: 

tiw riikt. Ikis UMI is ftllMH ky tM MKk ttxt m 7.4 

where "the right" did not fit on the right. 

If the texts both to the left and right do not fit, or the left 
fright) text cannot be completely wrapped around to the right 
(left), the entry is continued on another line. For example: 

hit Nt tM mdi text M tkt Itft. This UOM is ffllMH by fir tM Mck tf xt m... 
...thtrliht 7.4 

After locating an entry, proceed directly to the referenced 
section(s). If a reference is to Section X.Y, look on page X-Y 
first and you will usually be within a page of the desired 
referent. 
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, tilt ti lift 

lotlMM IffatiN: 

Equality CoiiMrisiiis: «> ml 

Nltipliativf Optritsrs: * / 

NiRtir liffrtiict: 

sizttf, 

lit-«iM IM: 

SifMMtiil OMJiMctiii: 



I. 
I. 



tilt U riilit « Stctiw 

."TTrTTTTrT TTflS 

11.5 

8.11 

1.14 

1.17 



5 1.27 I.M 

C 8 J 

U 8.8 



OvtrrUlRf Opintar PrictiMa: 

FwctiM Cill: 

PiiRtir Sfrfffrmci: 

Hyltifliativf Onrttirs: 

ISSKittiVt. 

Ust, 
itaary situ aptrtttrs: - mi 

IMitivt Optrtttra: 

Prifii iRcriMtt MMl iKriMMit: 

Ptstfii iRamNt Mi StaniNt: 

tssadttivt. *, 

lift •, 

Pfliattr Itrafiraaci mi laabar Salactiaa: 

list, \ \ 7, I 

Naltiflicativa OMratars: • 

OriariM Caaparisaas: 

Shift Oparttars: 

Oriarlai Oiivarisaas: < > 

IStipMNRtSI 

Eaaality CaaparisaRs: 

Ordariai Caaparisaas: < 

ONariaa Caaparisaas: < > <■ 

Skift Oparatars: « mi 

Caaiitiaaal Expratsiaas: 

list, •, ♦, 

8rr«y Mailai: 



llt-aisa Eidusiva-ar: 

\ \ i. 
_L«E_^ 



*, I, , aMi I caaaatativa aai assadativa. 



). 



o: 



\ 7. I 



I, ', iRi I caRMtttlN aai 
7, I 



ilt-alsa lRclHsi«a-ar: 

-, ♦. I. \ RRd 

lilt, •, ♦, ?, 

Sataaatial OisjvRctiea: 

iit-aisa Oaaplaflaat: 



7.12 
8.28 
8.24 
8.18 

/I. ..^ 8.14 

*, C, ", aatf I caaMtativa aai 7. 12 

. 2.2 

8.18 

8.13 

8.Z2 

8.23 

7.12 

. 2.2 

8.21 

. 2.2 

8.14 

8.11 

8.12 

8.11 

. 8.3 

8.18 

8.11 

8.11 

8.12 

. 8.4 

. 2.2 

8.2S 

\ 4.2 4.8 

\ u liaa caatlaaatar 8.2 

;; 8.8 

", aadl I caaaatativa aa4 assadativa 7. 12 

_FUE_. 5.9 

LI8I_^ -JIIi_ 5.8 

8.7 



/% 

< > <■ >•. 
« aai ». 
<« >• 



» aai i«. 

> <• >«. . . 
>• 






tha typa af a 4adaratar or 
Cast Typas mi 



caaaatativa aa4 assadativa 7.12 

2.2 

I M 

8.18 

_aks, _aia, jhuc 8.7 

abstract iadaratar 8.5 

Ihstract Badaratars 8.31 

8lsuaa_tfadaratar 8.5 8.31 

MstractlparaHatars 6.5 6.8 

prafaas fraa 8ia 6.1 

aMitiaa, sabUactiafl 8.13 8.22 8.23 

IMitiva Oparatars: « aai - 8.13 
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•Mriss If M trray B. 17 

fttuctim Mmi vtrsn ftiU-firactioti valut 1.5 

ip-lMil •MrtsslNf (1.5 

Utectlw 2.Z 

•djcctivcs start msIimI 1h|, sifiti. S.3 

anrifita iiititlizitiM fl.2 11.3 

scalir wi tMriftti ^s 3.5 

NMbir •lilMMt 8.4 

^inttr ili|RMiit 1.11 

stirift tlltcttlM 3.10 

Lfxical aniiilty 2.3 

lixical Milfsis 4.15 

llt-»lsi M: C I.S 

irpMnit cMwniN at fmctiM mtry I.l 

irfMMt tnt dndciii 1.24 

tfiMMt viiniii m4 tiMrtMiiii fl.l 

men puiMttrs iM irfiMiits 5.1 

Miriikls MMltr 0f iriMmits tt ■ fmctiM 1.24 

MiRtir irltftmUc 1.13 1.25 

irltlMUc ONftrsiNS 3. 13 3. 14 3. 15 7. 12 

irithMtic tmt 1.3 

iittirtl, flntlif, iritkMtic typts. 3.4 

•Mntt tf m UTtf 1. 17 

irr^ mi ompmmt typt 3.5 

Ndirttim mi irrqp ty^ 8.5 

•rr^ 4.1 

vrtys If ctaricttrs 1.31 

cmmrsim tf irriys ti piiitirs 1.17 1.21 1.29 

•sai 4.1 

rillit purt If KsipMRt 1.3 

llssiiMimt CMMtikility 3. 13 1. 3 

Issiimmts: » 1.3 

ImH Pinrnttr tosvciitim 11.4 

**, \ C, *, mi i cmmtativf mi mstditim 7.12 

cmmutivity, issiditivity 7.12 

precHmcf , nsfditivi^ in nprnsims 7. 12 

<DEUTE>, <II$JS> 2.2 

Stfrin.clnsR Mtt. nttra, rtiisttr. typHtf, stttic. 1.3 

mtmatic stirift diss 1.2 

disMS. MtMttic, static, mi typaitf sttrift . . 3.9 

MtMttic, tfptitf 1.3 

bmifi rtiafliiitim 5.8 

lit flrti 8.4 

llt-fiili iMftk 1.33 

lit-iiM 8ii: C 8.9 

lit-sist CMplMMt: ' 8.19 

8it-»isi Eidisivt-tr: * 8.8 

8it-fist ladssiw-tr: | 8.7 

bltck 8.1 

Sctpts. Blacks, Orisias, Dafiaiai Paiats, aai 3.2 

Nipti C ExtMsims Bacaantai la tlw Hamial Baiy 8.3 

aacra feaiy 5.8 

Bmlam latatim: ! 8.28 

llM haaaiarias 4.3 

Iraak 7.9 
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Iriif Tvtoritl m fnxaiyfn t.l 

hfU 8.21 

XMtl ExtMSiMS X» C 1.2 

Hilii C ExtMsinn DtOMMttl 1r Uw ImmI My. 1.3 

OMMsitiM ef • C fttvu 2.7 

rtMlt of finctiii all 7.11 

fiMctiM cill 1.4 

fMctiM call rtliikility i.l 

Null fMctiN oil SMMtics 1.24 

FMctiN Clll: 0. 1.24 

pniMS CilliH.cMVHtiN, tati, mi dit I.l 

cat! CMStMt 1.33 

cuf rtfifis 7.3 1.3 

ttitd. cast, itfMlt 7.3 

Cut lifts iMJ Ikstrict itdirtttrs 1.31 

}m CisU 1.15 

tyft tf ckar 1.3 

cktr, iat, flMt^ iNkli, taii 1.3 

<CIM> 3.4 

<StHI6>, <0m> 4.1 

<UTEGEI>, <f LOIT>, <QIM>, <OCTM.>, <IIEX>, <STIIK> 1.38 

Ckiractir Sit 4.1 

tarfft mi tast dMractir sit 4.1 

StriRfs mi Ctaractirs 4.1 

•ctal, hexaitciMl ii striifs ir4 chtricttri 4.1 

irrays if dMrtcttrs 1.30 

•riniHt xm dMcklRf 1.24 

stiri|i diss 3.11 

mtt, typi, stinii diss 3.3 

MttMtic stirioi diss 1.2 

starifi dissts 3.1 3.S 

MtiMtic, static, mi tyaatfaf stiriii dassis 3.9 

prifMS CilUiHLC i av ii tiia, lata, aai CmIi I.l 

CaabiaatiM af Oparaad Typas 3.15 

CMMt ipirttir 3.11 

Ciaai Opiratir: 1.2 

OMtril Liais: Pripricissir Owiiiais 4.14 

pnaricissir ciaaaNs. 4.15 

Caaaaat Caatral Liaa Laxicaa 5.3 

Oaaaaats 4.12 

Caiaaaicatiaa vitli athar LaafMfas I.l 

", *, C, *, aa< I caaaaUtiva aai assadativa 7. 12 

caaaautivlty, issiditlvity 7. 12 

_aa»t_ri9lit, cmmti 17 

OrtfiriRf ONpirisiRs: <><•>• 8.11 

Eimlity CMiMrisMs: •« M !> 1.16 

Issisaaiat CaaMtibllity 3.13 1.3 

Caaaatiklt Typas 3.12 

caapilatioa aait 2.7 

saparata caapilatiaa aaits 3. 11 

coaditlaaal caapilatiaa 2.1 4.15 

Bit-al$i CaaplNiMt: " 8.19 

array lai caapaaant type 3.5 

Coapisition of a C Progru 2.7 

CaapMAi StatiNMt 7.1 
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CMftM^.sUteiittit 3.1 S.3 

striif ctnctteRttion A.Z 

tnibUnf cMtfitlen 5.10 

cwKIUmH CMpiUtiM Z.e 4. 15 

CMiltlMil ExyrtnioRs: 7 : 1.4 

CMiitiMil iRclisiM 5.10 

StfBMtill OMJMCtlM: (S 0.0 

CIM CMStMt 8.33 

CMStMt txprtttiM 5. 10 

Omstait ExfrnsiMS 1.33 

CMStMt svfflns H.Z 

CMStMts 8.30 

CMStrtiRts 2.1 

CMstraints mi StuMtlcs 2.5 

cMstractitf tyfft 3.S 3.0 

instMct if cMStrnctlM 3.0 

CMttxt-fm irMMT 2. 1 2.2 

\ as liM CMtiMttfr 0.2 

CNUNt 7.10 7.7 

cMtimiiM I fir tlili, ir it statMMt. 7.10 

OMiMt ONtril LiM LtxlcM 5.3 

Otiwr CmUiI LiM LniCM 5.5 

CMtral LiM nirist Strictiri 5.0 

CMtrtl LiMS 5.2 

CMtrtl LiMs: Frtf rtcMtir Omnm#s 4. 14 

PrtfrM Tnt CMtMtiMs 2.4 

VfMMt CMVtrsiM tt fMCtiM NtTf 0.0 

cMMFsiM If irriys ti ^iitirs. 0.17 0.21 1.23 

OrittaNtic OMMrsiMS 3.13 3.14 

Iitioril UilMiif CMMrsiMS 3. 14 

irithMtic CMVirsim 3.15 7.12 

CMfirt 7.12 

prifits Cilliiii.cMVMtiM, Oata, mi CMt i.O 

rivflicati lidaratiM 3.2 

iKlaritlM pripirti Mt 3. 1 

OiclaratiM Pnptrty Sits 3.3 

stariif riicliritiMS 3.11 

lipliciti iKliritiMS 3.11 

ExtirMl iKliratiMs 0. 1 

SpKiflii iKlaratiMS 0.2 

ilakiratiMif iKlaratim 7.17.3 7.0 

iattmixini statmmts mi ItdaratiMS 0.3 

OldvltiMS Ml NfilitlMS 3. 10 

iitmixiif HclaratiMs Mi statiMits 7.1 

thi typi If I iicliritir ir ikstract iidiritir 1.5 

thi typi If I iKlaritir ir ifestrKt iidiritir 6.5 

Oiclaratirs 0.5 

Cut Typis aN Mstrict Oidaratars 1.31 

Prifix Incrmtflt ani OacrtMit: ♦♦ mi — i.22 

Pastfix iRcrtMit ani OtaiMat: *« ani — 1.23 

saitd, cui, ani iifMlt 7.3 

iitf iM aN fnitf 5.0 

iifiMi 5.10 

Olidcs. Orioins, hfiiiM Piiits, mi Somis 3.2 

Bacri Dafinitiofl LixicM 5.4 
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Nclirititiu wMI Itfinitioas 3. IB 

FMCtiM Sffiiitieos I.I 

iM-FimaiM MiiitiMS 1.7 

<KLnE>, <ISJS> 2.2 

Nliiitirs uii Eil 4.11 

tffi itMtttiM 3.4 

ItMtiiii Im Typts 3.5 

foliittr BcriftrMct iii4 Itiktr SiltctlM: -> 1.21 

Ptiittr NrtfirMca: • 1.11 

SaiMtUal lisJiictiM: || 1.5 

tfispliy 1.5 

MlUylicttiM, livisioa, Miulo 1.14 

CMtimiini • ftr, ifeili, ir if sUtMMt 7.11 

ixitini I siitd, ftr, •kill, ir tft stitnwat 7.S 

«t-fidli 7.1 

li|k C ExtMsiMS NciMMtt4 in tht M«mm1 My 1.3 

iMfl 4Mkli 1.2 

FlMt, iMklt, LMf-toikli 3.4 

ctar, iat, nttt, tfMklt, vtii 1.3 

*9licata «iclirttiN 3.2 

iiylicatt iKlmtiMs 3.11 

slii ifftcu 7.2 

ExprKsin EvalittiM, Siii Efficts, m4 Shnmci Nints 3. II 

slit* ifffct, sfvmca Mint 7.3 1.23 

tlitertUM If 4tcltratiNs 7. 1 7.3 7.1 

«if, HHtt HfUtt Hlif, Hlu, Haiif 5.11 

•1st li Itxicil iritttrs S.S 

tit Ifitt nfittf, ttlif, Hlu, «ntlf 5.11 

Mtkliii cMitfitlN 5.11 

••4-if-lUi 4.2 

fit iifitf, fifittf, ftlif, Hlu. iNtfif 5.11 

irfHMtt cwwtniM it futctiti Mtry iS 

strict, ttitt, tMM 1.4 

mtts stract-tti, Mdltt-tat, «MM-tM 3.3 

MMHrttiM littrtl 1.33 

MNMtritlN lltirils at4 typt 1.4 

fuKtiM pvfiit mi MvirMMMtt 1.5 

Nlititirstti Eil 4.11 

Efiality CNMristts: •> ati I* I. II 

EfiivtlMt Types 3.7 

•scipt sifitiicts 1.2 

•vtlMtiM irttr 7. 12 

PtiiU. ExprisslM EvtlHtiM, $141 Efficu, itt Shmki ... 3.11 

ExcltiH Tixt 4.13 

iRCliM m4 ExdiM lixt 4.4 

iit-nlst Exclssivi-ir: 8.B 

prtgrw ixtcitiN 2.7 

SUtMMt. ixitiif • stitch, ftr, thilt, or it 7.9 

rtflvlir ixprissiMs: list, *, *, 7, 1 2.1 2.2 

cMstwt ixprissiM 5. 10 

St^tMCt Nints. ExprtssiM EvilutlM, Sidi Efficu, in4 . . 3. II 

ixprission rNritini 7. 12 

pracsdMCi, assicistivity in ixprsssions 7. 12 

CMStiAt Exprissiws 8.33 

Exprissions as Stitinints 7.2 
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Oimditioflil Exprinins: 7 : 6.4 

ixtM^f i flMtlRf-pi int prtdsion 7. 12 

Nifh C ExtNsiMS NcwwRtetf ii the Hinual My. . D.3 

)0J11 ExtmsioRS to C «.2 

StiriH.clusts utt, iittn, rffitttr, tfytiff, sUtic 8.3 

Extirnil ItdiratiMs B.I 

Extariil.iltclaratioR S.Z 

min 9U, valM, foi, tfp«tftf 3.3 

fM*tck 4.15 

mtn iMktr, fiili 3.3 

lit fitW 1.4 

fill iiClniM 2.1 4.15 5.7 

stirct filts 2.7 

Jiwijitu. .skip.div, .filLcfctr 1.7 

fiui ckar, skip cHar, fill ckur 1.7 

flMt •«*!•, Lm|-N<*1i 3.4 

cktr, lit, flMt iMilt, ftii 1.3 

<WTEQEI>, <OCTIl>, <KK>, <fLOIT> 4.7 

<IITEQER>, <FLOIIT>, <CMI>, <(X:TM.>, <IIEX>, <STIII(2>. 1.38 

iittfril, flMtini^ iritlMitic typis 3.4 

ixtmM flNtiif-MiRt pndsiM 7.12 

CMtiiMiBi • ftr, iliit, ir if stitMNt 7. II 

txitiif t tiitcb, fir, ■hilt, tr te statMMt 7.i 

fMCtioR MMrtss vtrsM fill-fmctiM viIm 11.5 

RtstN FMACtiMs iM Fvll-FunctiM Hriiklts d.S 

ftri«blt nwibtr tf irimwiits tt i fMctita 8.24 

vtlM. flMCtlN wtimi ntVR mi-fMictlM H.S 

mtltif fmctiMcall 7.11 

fiRctiM all 11.4 

fmcUM call riliakility n.% 

Pascal fmctiaR call samatics 1.24 

FuRCtiiR Call: 1.24 

Foictiaa Nfiaititas S.I 

arpmaat ctavaniaa at faactiaa antry I.I 

fnactiaa paraat mi mviraRNaiit 1.5 

faactiaa pritatypas 1.2 

faactiaa aMms varsas fall- faactiaa valaa 1.5 

lastad Faactiaas mi Fall- Faactiaa Variallas 1.5 

pratatypa an4 aan-pratatypa faactianalitias 3.5 

foactionality typas aa4 pratatypa faactiaaalitin 1.5 I.I 1.24 

fanctiatwlitias. faactiaaality ^ppa md pratatypa .. 1.5 I.I 1.24 

faactiaaality typas 3.5 

racaniva faactiaas 1.24 

Nastai FaacUaas aatf Fall-Faactiaa Variablis 1.5 

Faactiaa iafiaitiaa 1. 1 1.2 1.3 I.I 

flabal mi lacal lifatiaas 3.1 

latas mi Lifeals 7.1 

coNttxt-ffH irnmar 2.1 2.2 

Qtumu Ratatiaa 2.2 

alsa ia laxical iraaaars S.S 

<I«TE(H>, <OCTM.>, <IIEX>, <FL«T> 4.7 

<inEGEI>, <PLCiT>, <CWII>, <OCTIl>, <«», <STIII6> 1.31 

actal, kaxaiadaal ia striafs aN diaractars 4.1 

Haaaal 8a4y. Rifli C Exttnsians DaoMtated in the 1.3 

targat an4 hast charactar sat 4. 1 
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<IIENTIFIER>, <TYKKF IMNE> 8.32 

<IIWTIPIEI>J .". i.23 

lintlfltrs 4.1 

if 7.4 

HUif. fif, flMtf, 9ifUt1, filif, i^lsi, ... S.ir 
tit fififf. fifMtt Ailif. •ilsr fMtfif. 5.11 

•it fifitt fifatftt «ilit Hlu. iraiif 5.10 

licliM mi ExdiM Tixt 4.4 

flit iaclMsiM 2.1 4.15 

CMtfitiMtl IndislM 5.11 

Flit IidMiM 5.7 

lit-«isi Iidijiw-ir: 1 1.7 

iKMpliti strKtm ir mIm tin 1.4 

iiicMplitt xnn 3.5 i.5 

iiftmatlM iKTitsiii. 3. 11 

Prifix iKrtRNt u4 NarHMt: ** mi — 1.22 

Nstfix iKTtiMt mti ttaimt: «« w4 — 1.23 

' iuinmimt trwslttiM 2.7 3. 11 3.7 

Irriy Iniixiiii: [ ] 1.25 

iifirMtlM laaiuiii 3.11 

iRfinatlN siiiltr 3.11 

laiUiliziniRi iRlUilinUM 1.7 

iiiUilizitiN 7.3 7.11.33 

•Hrifati iiitiilizatiM i.2 1.3 

iRlUilizfn mt iRititliztUM 1.7 

iRStMCt tf CMStriCtiM 3.1 

dMT, ilt flMt, tfMllt, Mil 1.3 

<1iEX>, <STIIW>. <IITESI>, <FLOII>, <CMI>, <OaaL> 1. 31 

<inEGEI>, <OaiL>, <ttX>, <FLai1> 4.7 

iRtiinl miMiRi CMvtniMS 3.14 

iittinl. flMtiii, tritkMtic typM 3.4 

iRUniixiRi liclirttiMt mi stttMNts. ..7.1 
iittraixlRfl statMMtts Ml itclirttitn. ..1.3 

laUiuia 1.7 

iriiatry, U|, liMl, Ml suna mi niN mm shcis. . . 3.1 

scapt If IMils 7.1 

Mtts m4 Litals 7.1 

CoMMlcatiM witli itkir i M iii mt Ki 

fcit-fiiU iMitk 1.33 

LMictl MfeiiMitjf 2.3 

lixicil Mtlytis 4. 15 

•Isa ia Ifxictl iTMMrs 5.5 

s|ttix. lixicil vtrsM plrtst-structari 2. 1 

ItxicM 4.15 

Prifricissir m4 LixIcm 4.3 

CMMit CMtrol LIm LtxicM 5.3 

Ittri MfiiitiM LtxicM 5.4 

OtMr CmUoI LIm LixIcm 5.5 

LixicM vf rsw Nirtsi-SUuctyri 2. 1 

LifttiMS 3.r 

llMal m4 loctl lifttlMS 3.t 

llM toMdtrin 4.3 

\ u liM CMtiMttfr 11.2 

CoiMMt Conuol LIm Lexicon 5.3 

Ottor CmUiI LiM LixicM 5.5 
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CMtrol LiM fhrui Strvctire 5.6 

LiM S^lidRj 4.2 

CMUfl Hum 5.2 

Control LlMs: Prtproctssor Comnds 4. 14 

stotic link (1.5 

liikiRf 2.7 

riftlir oxprissioRs: list, •, ♦, ?, 1 2.1 2.2 

MMnNrttioN litortl 8.33 

tmmtritiM litorils mi tff 6.4 

llifeil ui local lifotims 3.1 

1M| tfNklo 11.2 

•djfctivts skfrt nsifMi, iMif, sifiH 6.3 

Floit B«A1«, Loif-Niklo 3.4 

IvtlM, rvtlM 3.3 

men My 5.8 

Raao Ooflnitioi Loiicwi 5.4 

mcro ptruMttrs mi urfMtRts 5.1 

Mcro rnlicotMiit 2.1 4.15 5.16 5.6 

Rktos 5.6 

MfiMtorloss Mtf jMriMttrizN mens 5.6 

fn^ffimtf iKns 5.8 

Ni6li C Extoflsiotn NcMMtid in tiM IommI Htf 11.3 

jki, .iio, jm i.7 

iionbtr iliiMMt 6.4 

m4tt MMbtr, fitli 3.3 

Nintor Bonforoflct mi Itntar Stloctim: -> 1.26 

MiiNr Soloctloo: 6.27 

mmtr-Ust 3.5 

stractvn or mioo M«Nr$ 6.4 

.tij, .Mill, jm 6.7 

wtti, typo, stirofo diss 3.3 

mitt Miltr, fitU 3.3 

m4os strKt-ttf, NiM-taf, taM-ta|. . 3.3 

mtn fir, vtlw, fca, ^PpHof 3.3 

Mltlpllcttloii, riioisloR, m4ilo 6.14 

_m«o, Mvojiilt, jconftn li-7 

.mvo, _mm ri|kt coiiMro ....1.7 

Nltif licttioa, difisiw. m*ilo 1. 14 

NltipliaUft Oporotors: • / t 6.14 

tai mm spaco 6.4 

Rom SpKOS 3. 1 

ordimry, tif , labtl, «d stnct ood ooion mm spacn 3. 1 

Romd Ptromm 6»oclotloii 6.4 

loms 1.32 

pviMtor Roms ORd typos 6.5 6.6 

typo moos u piramtors 6.5 

RtfttiN 6.18 

6oolom ItHtion: 1 6.20 

Viriiblis. Nistod Fonctiiis md Foll-Fmctioii 6.5 

Semtinf Nov Typos 3.5 

Roo-Foiictloo Pofliitloos 6.7 

prototypo oN Mo-prototypo fmctloMlltios 3.5 

Ion fMctiot dcfioitioii 6.3 

Nofllftmctiooldtfioitions 6. 1 6.2 6.7 

Gronmr lotitioo 2.2 



V.11.01.B5 



© 1984-BS HetaUare Incorporated 



Index: HighC** Language Reference Manual page I-IO 

typt MtatlM 3.5 

Tht lill SUttMit 7.12 

variiblt mnfeir if iriiiMits ts t fuactlu 1.24 

iMfetrs 4.7 

Miincirts in iMwfetrs I.? 

sizt tf ifcitct 3.i 

Valws, Typts, vti Oljtcts 3.4 

dMrtcttrs. icul, InxiitciMl in striiis Ml 4.1 

<IITEGEI>, <OCTIL>, <lltX>, <FLOII> 4. 7 

<IITE(IR>, <FLOIT>, <aiM>, <OCTM.>, <NEX>, <STRIII<i> 1.31 

ONliMtiM tf dfnmi Typts 3. 15 

csMM iffritir 3.U 

Ovirriiiii Optrttir frtcrtmct: < } I.Zt 

Cnm Optrttir: I.Z 

Optrturs 4.8 

lultiplictUM OHrtttrs: " / 1 1.14 

IMitivt Qpirtttrs: * mt - 1.13 

Vitry sip tptratirs: - m4 * 1.11 

Siift Opfratars: «mt» 1.12 

•¥tlwUM iritr 7. 12 

OriiriPi ONptrims: <><>>■ 1.11 

MM sptcis. iriiMry, tai, labil, mi strict mi mdm . 3.1 

IlKks, Oriiiis, Nfliiii NiiU^ ui Scipis 3.2 

Ottor Cutnl LiM LiiicM 5.5 

Ovtrriliii Optrttir Priolnci: ( ) 1.21 

lurt PiriMtir IsMdttiN i.4 

pviMtir MMS mi typts S.S I.I 

ptriMtir typis 3.! 

puMitirliss mi puMitirizil Ncns S.I 

pviMtirlns mi piriMtirizMI Mais. ... 5.1 

FiriMtirs 1.5 

rifistir piriMtirs 1.5 

typi MMS u piriMtirs 1.5 

rtfistir ptriMtirs I.I 

pisitliMl piriMtirs 1.4 

Mori ptriMtirs mi iriMMts 5.1 

fWCtiN pVMt Mi MViriMMt. . . . . ; 1.5 

riflit part if issipMit 1.3 

Pisal 1.5 

tascal fMctlM cill SMMtics 1.24 

CMtril LiM PIrist Strictiri 5.1 

LixicM Mrsm Pkrasi-Strictiri 2. 1 

pkrisi-stractin 4.15 

lixicil vtrsus pkrisi'Striictiri syntu 2. 1 

si*- iffKt, siVMici piiit 7.3 1.23 

SIMMCf piilt. ... 7.12 7.4 7.5 7.6 7.7 1.24 1.4 1.5 I.I 

piiitar ali|MMt 1.11 

piiitir m4 trriy typis 1.5 

Mintir tritkMtic 1.13 1.25 

->. fiintir ItrifarMc* mi Ntiikir Silictim: . I.2f 

Piiatir lirafarMCi: • I. li 

Piinttr Rifirnci: i 1.17 

piiitir typi 3.5 

CMvirsiM of arriys to piintirs 1.17 1.21 8.29 

Evaluation, Sidi Efficts, anl Sivianca NiiU. Exprissioa 3. II 
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llocks. Origins, Dtfinini Piints, mi Sctfts 3.2 

positional parmttors 0.4 

— . Postfix Inaenont mi Deaenint: ** ni .. 8.23 

pript 6.1 7.m.3 

CMk. prifiras Cilliiii.coiivfntioR, Dita, aN d.l 

praiMS froN Na 8. 1 

prtcadoaca, associativity in oxprossions. . 7. 12 

Ovorriiinf Oporator Proco^ooco: ( ) 8.28 

oxtonM flnting-point prodsioi 7. 12 

Prodof inotf Rtcros. 5.9 

Pnflx iRcroNtiit mt NcroMiit: ** aN -. 8.22 

prifroctssir 2.7 

Umi is a ProfrM a Prifraii: tkt Prtprtctssor 2.8 

Proproctssor mi LiiicM 4.3 

Ooatrol Lints: Proproctssor Coatatls 4. 14 

proprocossor cotaanis 4. 15 

Prtprocossor Uiris 5. 11 

Omptsititn tf a C ProfroN 2.7 

Uhtt is a Profrat a Prafraa: tlw Prtprtctssor 2.8 

trtfrti txtdtita 2.7 

PrtfraH Ttxt OMWMtltas 2.4 

Uhtt is a PrtsTM a Prograt: tkt Proproctsstr 2.8 

itclaratita proptrtp stt 3. 1 

itclaratiti Prtptrty Stts 3.3 

fvictioaalitios. prototypt an^ nto-prttttypt 3.5 

foictioMlity typos «< prototypt fotctioinlitios 6.5 6.8 

fitctitMlity typt mi prttatypt fttctinalitlts 8.24 

foRCtitt prtttQppts 8.2 

8ritf Tittrial at Prttttypts 8.8 

PiRcttattrs 4. 18 

cast rttfts t 7.3 8.3 

rtctrsivt fatctiots 8.24 

koaip ro^ofiaitiot 5.8 

Niotor loforotco: C 8. 17 

ttftrttcts 1.7 

Stctita taftrtncts 2.6 

rtfistir paraMttrs 1.5 6.8 

Storait.classts Mtf, tittn, rtfisttr. tn^M, static 1.3 

L .. . rtfilar axprtssiots: list, *, *, 7, ... 2.1 2.2 

foictioii call roliohility 8.8 

nacro roplaconont 2.8 4.15 5.18 5.8 

roplocoimit toxt 5.8 

rosorvtri otri 2.2 

tostrvttf vtrtfs 4. 15 

rtsilt tf fatctita call 7.11 

rttirt 7.11 

txprtssita rtoritini 7.12 

riikt part tf assifmiMt 8.3 

Ivaltt, rvaltt 3.3 

SantTypts 3.8 3.7 

Sana tariallt 3.7 

scalar and anrtfttt typts 3.5 

sctpt of lakels 7.8 

81pcks, Origins. Bofining Points, and Scapts 3.2 

Section Nforencos 2.6 
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PsiRttr Itriftretict mil NMktr Siltctioii: -> 1.26 

iMbflr Stlactiw: 1.27 

Cwuuiints aatf SiMMtia 2.5 

PUCal fMCtlM call MRMtiCS 1.24 

ufUhU coRiilitiM units 3. V 

Site-lfffCt, StVIMCt psiRt 7.3 1.2^ 

si^ttiCi palRt 

7.12 7.4 7.5 7.17.7 1.24 1.4 1.5 1.1 

ExprissioR EvtlMtiiR, Site EfftcU, iM St^wRca NiRts 3. II 

iscapt u^uaRcas 1.2 

Sa^yaatiil OMlwctiai: cc I.I 

SavMRtiil lisjiRctiaii: || I.S 

iacliratiaa prafarty sat 3.1 

Cbartctar Sat 4.1 

tariat and liast charactar sat 4. 1 

laclaratiaa Praparty Sats 3.3 

sbariai 4aclaratiaas 3. 11 

Skift Oparatan: « ani » 1. 12 

aijactlvas sftart, wulpttf, 1mi|. si|Mi 1-3 

argaaaat aiiaalai aai slwrtaaiRi I.I 

sila-affaa, safwaca paiit 7.3 1.23 

silaaffactt 7.2 

Eiprassiaa Evalaatiaa, Siia Effacts, yd Sayiaaca f aiats 3. 11 

laary si|a aaaratars: - mi * I. II 

arijKtivas skart, MaiiMd, IwH* ai|M4 1.3 

sifMii 1.2 

Sifaatf-'ciMr,' lliisiiRaiHaMr.' '.!!!!!!!!!!!! 3!4 

Si|Ra4-Iat 4.i 

Sipad-lRt, lasiiaad-lRt 3.4 

Hasiiaai-Laiii-lRt. Si|aH-Iat, lasi|aa4-lRt. Siiaa4-Laft|-lRt, . 4.7 

Si|aa4-Laai-Iat 5. II 

Si|Ra4-Laa|-lRt, lRsigRt4'La«|-lRt 3.4 

Si|Ra4-lBt, Hasignad-Iat, Si|Ra4-LaR|-lBt, HRsiaaai'LaRfl-lRt 4.7 

Si|aa4-Skart-Iat, lasi|aai-Siiart-lRt 3.4 

iafarmtiaa siiilar 3. 11 

siHilar typas 3.12 3.7 

arriy siza 1.33 

siza af akjact 3.4 
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More Jheedback, Flease 

(After some use.) 

We would greatly appreciate your ideas regarding im- 
provement of the language, its compiler, and its documen- 
tation. Please take time to jot down your ideas on this page 
(front and back) and on additional sheets as necessary as you 
use the software. Then, after you have some significant 
experience with the software, please mail the results to: 

MetaWare^ Incorporated 

412 Liberty Street 

Santa Cruz, CA 95060 

MetaWare may use or distribute any information you supply 
in any way it believes appropriate without incurring any obli- 
gation whatever. You may, of course, continue to use that 
information. If you wish a reply, please provide your name and 
address. Thank you in advance. The Authors. 

Page Comment 
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